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and fragmentation Is not allowed (the DF Bit is set), than the size of th© MTU used should be 
lowered. There Is no active measures with Sun Solaris as far as I know. 

This Is a simple operating system fingerprinting method, which does not require additional or 
unusual patterns to be set 

The following operating systems where queries and chocked for this kind of behavior 
Linux Kernel 2.4 test 2,4,5,6; Linux Kernel 2.2 x; FreeBSD 4.0, 3.4; OpenBSD 2.7,2-6; 
NetBSD 1.4.1,1.4.2; BSDI BSD/OS 4.0,3.1; Solaris 2.6,2.7,2.8; HP-UX 10,20, 11.0x; 
Compaq Tru64 5.0; Aix 4.1,3.2; Irix 6.5,3, 6.5.8; Ultrix 4.2-4.5; OpenVMS v7.1~2; 
Novel Netware 5*1 SP1, 5.0. 3*12; Microsoft Windows 9B/98SE/ME, Microsoft Windows NT 
WRKSSP6a, Microsoft Windows NT Server SP4, Microsoft Windows 2000 Family. 



6.2.1 Avoidance 

With Sun Solaris and HPUX operating systems we can use a configuration option in order not to 
use the DF bit with the ICMP Query replies 31 . With HP-UX 10.30 and 1 1 .x it would not allow the 
Path MTU Discovery process with tCMP Query replies to be done. This would avoid the 
fingerprinting method I have introduced, which is based on the fact the DF bit Is set on ICMP 
Query replies from Sun Solaris, and HP-UX 10.30, and 1 1.x. 

With HP-UX 10.30, & 1 1.0 32 , one of the ndd command option is the ip_pmtu_strategy. The 
variable settings for this option are either 1 or 2. If this bit value is 2, than the Path MTU 
Discovery Process Is used with ICMP Echo Requests. This Is the default value. If this bit value 
equals 1, than the HP-UX machines will not use the ICMP echo-request PMTU discovery 
strategy, and will not set the DF bit after determining the accurate PMTU. 

To turn off [p_pathjfntu_diseovery on a Sun Solaris, machine use the following command as root: 

# ndd,-aet /dev/ip ipjc>ath_mtu_aiscovery 0 



Than when the ICMP Echo Reply Is sent (this example) the DF bit is not set 

# Sim v:U0*>aca7' initiated on Host_AddreSS at ?hu Sep 14 10:01:02 2000 

# Command line: 

# -> sing -c X -X» Host^Addreqa 

SINGing to Host^Address (IP_Addres5) : 1€ data bytes 

16 byte© from 10»13. 57,20: icmn_eeq=o. ttl=254 tos^o time^i.578 ras 

Host_AddreaB sing statistics 

1 packets transmitted, 1 packets received, o% packet loas 
round-trip min/avg/max « 1.57B/1.57B/1»578 ms 

# SXNG finished at Th U Sep 14 10:01:02 2000 



This was tested against Solaris 2.5.1, Solaris 2.6 and Solaris 2.7, all SPARC boxes. 

Beware - With Sun Solaris turning this option off, will turn off the PMTU discovery process with 
TCP as well. This is not recommended because of performance issues. 



I <fo ml have any information regarding AIX. 
32 BuRdIng a BasHon Host Using HP UX 11, Kevin Stevona, htlp^f^oplB.hD^e/stevesk/b&sUQnl 1 .html . 
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6.3 The IP Time-to-LiVfi Field Value with ICMP 

The sender sets the time to live field to a value that represents the maximum time the datagram Is 
allowed to travel on the I nterriet 

The field value is decreased at each point that the Internet header Is being processed. RFC 791 
states that this field decreasement reflects the time spent processing the datagram. The field 
value Is measured In units of seconds. The RFC also states that the maximum time to live value 
can be set to 255 seconds, which equate 4.25 minutes. The datagram must be discarded if this 
field value equals zero - before reaching Its destination. 

Relating to this field as a measure to assess time is a bit misleading. Some routers may process 
the datagram. faster than a second, and some may process the datagram longer than a second. 

Tne real intention Is to have an upper bound to the datagrams lifetime, so Infinite loops of 
undelivered datagrams win not jam the Internet 

Having a bound tp the datagram's lifetime help us to prevent old duplicates to arrive after a 
certain time elapsed. So when we retransmit a piece of information which was not previously 
delivered we can be assured that the older duplicate is already discarded and will not Interfere 
with the process. 



The IP TTL field value with ICMP has two separate values, one for ICMP query messages and 
one for ICMP query replies. 

The TTL field value helps us identify certain operating systems and groups of operating systems. 
It also provides us with the simplest means to add another check criteria when we are querying 
other host(s) or listening to traffic (sniffing). 



6.3.1 IP TTL Field Value with ICMP Query Replies 

We can use the IP TTL field value with the ICMP Query Reply datagrams to Identify certain 
groups of operating systems. The method discussed in this section Is a very simple one. We send 
an ICMP Query request message to a host. If we receive a reply, we would be looking at the IP 
TTL flelc( value in the ICMP query reply. The next table describes the IP TTL field values with 
ICMP Echo replies for various operating systems. According to the table we can distinguish 
between certain operating systems; 



Operating System 



IP TTL on ICMP datagram* 



UNUX Kernel 2.4 
Kemal £2.14 
Kernel 2.0** 

FreeBSD4,0 
FreaBSD3.4 
Open BSD 2.7 
OpenBSD 2.6 
NetBSD 

BSDI BSD/OS 4-0 
BSDI BSD/OS 3.1 



255 
255 
64 

255 
255 
255 
255 
255 
255 



Stephana Omnos provided Information about LINUX Kernel 2.0.x. 
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Operating System 


IP TTL on ICMP datagrams 
- t In Reply *■ 


Solaris 2.5.1 


255 


SOjarts 2.6 


255 


Solaris 2.7 


255 


Solans z.o 


2SS 


HP-UX v1 0.20 


255 


HP-UX v1 1.0 


255 


Compaq Tnj64 v5.0 


64 


irtx 6,5.3 


255 


Irix 6.5,a 


255 


A1X4.1 


255 


A1X3.2 


255 


ULTRlX4.2-4,5 


255 


OpanVMS V7.1-2 


265 


Windows 95 


32 


Windows 96 


123 


Windows 98 SE 


128 


Windows ME 


123 


Window* NT 4 WRKS SP 3 


128 


Windows NT 4 WRKS sp Ha 


12* 


Windows NT 4 Server SP4 


125 


Windows 2000 Family 


123 



Table 5: IP TTL Field Values in replies from Various Operating Systems 

If we would look at the ICMP Echo replies IP TTL field values than we can Identify a few patterns: 

• UNIX and UNIX-like operating systems use 255 as their IP TTL field value with ICMP 
query replies* 

• Compaq Tnj64 5.0 and LINUX 2.0.x are the exception, using 64 as its IP TTL field value 
with ICMP query replies. 

• Microsoft Windows operating system based machines are using the value of 128. 

• Microsoft Windows 95 ts the only Microsoft operating system to use 32 as its IP TTL field 
value with ICMP query messages, making It unique among an other operating systems as 
wen. 



With the ICMP query replies we have an operating system that is dearly distinguished from the 
other - Windows 95. Other operating systems are grouped Into the " 64 group" (LINUX based 
Kernel 2.0,x machines & Compaq Tru64 5.0), the "255 group" (UNIX and UNlX*e) f and Into the 
"128 group" (Microsoft operating systems). 

Wb are not limited to ICMP ECHO replies only. We can use the other ICMP Query message 
types as well, and the results should be the same. In the next example an ICMP Tlmestamp 
request is sent to a Redhat 6.1 LINUX. Kernel 2.2.12 machine: 

[root@stan /root3# icmpush -tstcunp 192.1S8.5-S 
kenny.ByS-eecurity.com -> 13:48:07 
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The Snort Trace; 

01/26-13:51:29.342647 192.168.5*1 -> 193,168.5.5 
ICMP TTI»:254 TOSrOxO ID; 13170 
TIMESTAMP REQUEST 

88 16 P8 D9 02 8B 63 3D 00 00 00 00 00 00 00 00 c° 

01/26-13:51:29.342885 192. 168.5*5 -> 192*168.5.1 
ICMP TTL;255 TOS=0x0 ID: 6096 
TIME STAMP REPLY 

88 16 D8 D9 02 8B 63 3D 02 88 50 18 02 88 SO 18 C^«.P»..P» 

2A DK 1C 00 AO F9 * 

IP TTL field value is 255 (the machine is on the same LAN). 

We can use this information with other tests as, to provide us extra criteria with zero effort 



6.3.2 IP TTL Field Value with ICMP ECHO Requests 

The examination of the iP TTL field value te not limited to ICMP Query replies only. We can learn 
a lot from the ICMP requests as well. The following Is a Table summarizing various operating 
system default values for the IP TTL field embedded Inside an ICMP Query request! 



Operating System 


IP. TTL on ICMP datagrams 
- m Reply 


: IP TTL : on ICtyP d^^rris ' 


Debian GNU/ LINUX 22. Kernel 2.4 test 2 


255 


64 


Redhal LINUX 6£ Kernel 2.2114 


. 255 


64 


LINUX Kernel 2.0^ 


64 


84 


FroaBSD 4.0 


255 


25S 


FraeBSD 3.4 


255 


255 


OpenBSD 2.7 


255 


255 


OpenBSD 2.6 


255 


255 


NetBSO 


255 




BSDI BSD/OS 4.0 


255 




BSDI BSD/OS 3.1 


255 




Sdarfe 2.5.1 


255 


255 


Solaria 2.6 


255 


255 


Solaris 2»7 


2S5 


255 


Solaris 2.8 


255 


255 


HP-UX y1 0.20 


255 


255 


HP-UX v1 1-0 


255 




Compaq Tru$4 *5.0 


64 




mx6.5\3 


255 




Irk 6.5.8 


255 




AIX4.1 


255 




AIX3J2 


255 




ULTRIX4.2-4.5 


255 
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Operating System / 

■j * i m ' t ' 


JPTTLon ICMP tetearams 
• - In Reply - " 


IP TTL on ICMP datagrams . 
-In Req,- ' 


OpenVMS v7.1-2 


255 




Windows 95 


32 


.32 j 


Windows 96 


129 


32 


Windows 96 SE 


123 


32 


Windows ME 


12a 


32 


Windows NT 4 WRKS SP 3 


12a 


35 


Windows HT 4 WRKS SP 6a 


128 


32 


Windows rVT 4 Server SP4 


128 


32 


Windows ZOOO Professional 


128 


128 


Windows 2000 Server 


128 


128 



Table 6; IP TTL Field Values in requests from Various Operating Systems 



The ICMP Query message type used was ICMP Echo request, which is common on all operating 
systems tested using the ping utility. 



• LINUX Kernel 2.0.x, 2.2.x & 2.4.x use 64 as their IP TTL Field Value with ICMP Echo 
Requests, 

• FreeBSD 4.1 . 4.0, 3.4; Sun Solaris 2.5.1 , 2.6, 2.7, 2.8; OpenBSD 2.6, 2.7, NetBSD and 
HP UX 10J20 use 255 as their IP TTL field value with ICMP Echo requests. With the OSs 
listed above the same IP TTL Field value with any ICMP message Is given, 

• Windows 95/98/98SE/ME/NT4 WRKS SP3,SP4,SP6a/NT4 Server SP4 - all using 32 as 
their IP TTL field value with ICMP Echo requests. 

• A Microsoft window 2G0O Is using 128 as its jp TTL Field Value With ICMP Echo 
requests. 



We can distinguish between LINUX, Microsoft Windows 2000, the other Microsoft operating 
systems group, and the *255 group" using this method. 



6.3.3 Correlating the Information 

Using the IP TTL field value wtth ICMP messages we can distinguish between Microsoft Windows 
2000, certain Microsoft Windows Operating systems, LINUX Kernel 2.2.x & 2Ax, LINUX Kernel 
2.0 jc, and the *BSD and Solaris group. 



Operating System * , 


. IP. TTL value Jn ttas'ECHO Request* 


IP TTL v^ue Jn the ECHO Replies 


Microsoft Windows Family 


32 


128 


*BSD and Sofcrls 


25S 


255 


LINUX Kernel Z2jc & 2.4.x 


64 


2S5 


UNUX Kernel 2.0* 


64 


64 


Microsoft Windows 2000 


128 


12$ 


Microsoft Windows 95 


33 


32 



Table 7: Further dividing the groups of operating systems according to IP TTL field value in the ICMP ECHO 

Requests and in the ICMP ECHO Replies 
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One would expect that the IP TTL field value would be the same with both ICMP Query requests 
and ICMP Query replies. Apparently this Is not true and provide us with valuable information 
about the operating system querying / being queried. 



6.4 Using Fragmented ICMP Address Mask Requests (Identifying Sun Solaris & 
HP-UX 11.0X machines) 34 

It appears that only some of the operating systems would answer an ICMP Address Mask 
Request as It Is outlined in Table 2 in section 2.5. Those operating systems Include - ULTRIX 
OpenVMS, Windows 95/98/93 SE/ME, NT below SP 4, HP-UX 1 1.0x and SUN Solaris. How can 
we distinguish between those who answer the request? 

This Is a regular ICMP Address Mask Request sent by SING to a SUN Solaris 2.7 machine: 

[rootGaik icmp]# ./sing -mask IP_Address 

SINGing to IP^Address (IP^Addreas) r 12 data bytes . 

12 bytes f ronTlP_AddresB .-^icmp_ae<*=*0 ttl=236 maak-255 .255 .255 . 0 

12 bytes from IP_Address : icmp^Heqol ttl£=236 mask=255 ,255 , 255 .0 

12 bytes from IP_AddresB : icmp_fl.eq~2 . wask-255. 255. 255.0 

12 bytes from IP^Address ; ttl-236 maek=255.255 *255 ,0 

12 bytes from IP^AddresBT icnrp_eeq=>4 ttl=236 mask-255 . 255 . 255 . 0 

lP_Address sing statistics 

5 packets, transmitted, 5 packets received/ 0% packet loss 

AQ operating systems that would answer with ICMP Address Mask Reply would reply with the 
Address Mask of the network they reside on. 

What would happen If we would Introduce a little twist? Lets say we would send those queries 
fragmented? 

In me next example, I have sent ICMP Address Mask Request to the same SUN Solaris 2,7 box, 
this time fragmented to pieces of 8 bytes of IP data. As we can see the answer I got was unusual: 



[rootdaik icmp] # ./aing -mask -C 2 -F 8 IP_Address 
SINGing to IP_Addrese (IP_Addreas) : 12 data bytes 
12 bytes from IP_Address : icnrp_seq=0 ttl=«241 raaak-0 . 0. 0 . 0 
12 bytes from IP_Address: icmp_seq-l ttl-241 mask-0 . Q. 0 »0 

IP_Address sing statistics 

2 packets transmitted, 2 packetB received, 0% packet loss 
[rootGaik icmp] # 

The tcpdump trace: 

20:02:48.441174 pppO * y.y.y.y > Host_Addrees : icmp: address mask- 
request (frag 13170:8®o+) 

4500 ooic 3372 2000 f£oi 50ab yyyy yyyy 
xosc 1100 aee3 401c oooo 

20:02:48.442858 pppO > y.y.y.y > Hoot_Address : (frag 13170:4®B) 

4500 0018 3372 oooi £f oi 70ae yyyy yyyy 
soooc X500C 0000 0000 



The Solaris portion was also discovered by Alfredo Andres Omella. 
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20:02:49.111427 pppO < Hoat_Addresa > y-y~y\y: icmp: address ma.sk is 
0x00000000 (D?) 

4500 0020 3618 4000 flOl 3c01 xxxX XXXX 

yyyy yyyy 1200 ade3 aoic 0000 0000 0000 

20:02:49.441492 pppO > Y-Y-y-Y > ttost_Addresa r icnrpj address wak 
request (frag 13170:830+) 

4500 OOlc 3372 2000 ffOl 50ab yyyy yyyy 

XXXX xxxx 1100 ade3 401d 0100 
20:02:49,442951 pppO > y.y.y>y > Host_Addrees : (frag 13170:4®8) 

4SO0 0018 3372 0001 ffOl 70ae yyyy yyyy 

xxxx xxxx 0000 0000 
20;02:5b.oii433 pppo < Host_Address > y.y.y-y: icmp: address was* is 

0X00000000 (DP) 

4500 0020 3619 4000 £ 101 3c00 xxxx xxxx 
yyyy yyyy 1200 ace3 401c 0100 0000 0000 

The same SUN Solaris box now replies with a O.O.Q.O as the Address Mask for the Network It 
resides on. The same behavioral patterns were produced against an HP-UX 1 1 ,0x operating 
system based machine 35 . 

What would happen with the other operating systems? 

They all would respond with the real Address Mask in their replies. 

Here we got a distinction between SUN Solaris & HP-UX. 11. Ox based machines to the other 
operating systems that would answer those queries. 

In Section 6,2 we were discussing the various issues regarding the DF Bit usage within the ICMP 
Query replies. Both SUN Solaris and HP-UX 11. Ox set the DF Bit by default In their ICMP Query 
replies, HP-UX 1 1 ,0x based machines starts setting the DF Bit after they finishes the ICMP based 
PMTU Discovery process (Querying the Host that has queried them with ICMP Echo request) - if 
it Is enabled by default This gives us another means to distinguish between those two operating 
systems on top of another method. 

We can further try to distinguish between the remaining operating systems. This, if we would use 
the t=0 code method i am going to Introduced In section 6.8; 

Important notice; When I have tested this method I have encountered some problems replicating 
the results with different ISPs. As it seems from analyzing the information I got, certain ISPs 
would block fragmented ICMP datagrams. This behavior would not enable this method to 
succeed. One way of testing this Is to send a regular ICMP Echo request We should watch for a 
response from the probed machine. If received, than we should send ICMP Echo request, this 
time fragmented, tf no reply is received than your ISP is blocking ICMP fragments probably. 



35 Whan I have published this Information in BUQtraq (August 5> 2000) Peter J. Hofcer notified me that HP-UX 1 1.00 
produce the same behavior as the SUN Sularia boxes. Darren Reed also noted that because SUN Solans and HP-UX 
.11.0 share the same third party (Mental) imptementeflon for some of their TCP/IP stacks this behavtorte produced by 
both. 
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ICMP Address Mask Request 




Sun Solan's Other OS's 



HP4JX11.0X 
UltrixOpenVMS 
Windows 95/98/98 SE/NT Below SP 4 



ICMP Address Mask Request Fragmented 

Reply with the 

Reply with O.Q.O.o / \ same Address 

MaskasinStep 1 



Sun Solaris Utrix OpenVMS 

HP-UX 11, Ox Windows 95/98/08 SE/NT Below SP 4 



Q) ICMP Address Mask Request 
With Code field 1=0 



Reply with code=0 



Reply with codel=0 



Windows 95/98/98 SE/MT Below SP 4 UHrix OpenVMS 
Diagram 5: Finger Printing Using ICMP Address Mask Requests 



Using Crafted ICMP Query Messages 



Playing with ths TOS Field 

Each IP Datagram has an 8-bit field called the TOS Byte", which represents the IP support for 
prioritization and Type-of-Servfce handling. 



o 



5 « 



Precedence 



TOS 



MBZ 



Figure 1 1: The Type of Service Byte 
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The TOS Byte" consists of three fields. . 

The "Precedence ftelcT, which Is 3-blt long, Is Intended to prioritize the IP Datagram. It has eight 
levels of prioritization 35 : 



Precedence • 


Definition. ' ' : 


0 


Routine (Normal) 


1 


Priority 


2 


Irnmedlete 


3 


Rash 


4 


Plash Override 


5 


Critical 


6 


Internetwork Controt 


7 


Network control 



Table 8: Precedence Field Values. 



Higher priority traffic should be sent before lower priority traffic. 

The second field, 4 bits long, fe the Type-of-Service H field. It is intended to describe how the 
network should make tradeoffs between throughput, delay, reliability, and cost In routing an IP 
Datagram. 

RFC 1349 37 has defined the Type-of-Servlce" field as a single enumerated value, thus 
interpreted as a numeric value rather than independent flags (with RFC 791 the 4 bits were 
distinct options, allowing combinations as well). The 4 bits represents a maximum of 16 possible 
values. 



Value (Hoxy 


Vafoe'iOec) 


Value (Binary];i 


Service 


0 


0 


0000 • i 


Normal 


1 


1 


1000 


Minimize Oeley 


2 


2 


0100 


Maximize Throughput 




4 


0010 


Maximize RufeWtily 


8 


S 


0001 


MinlrtitzaCost 


I F 


15 


1111 


Maxlmb» Saeurfry 38 



Table 9: Type-of-Servlco Fteld Values 



What about the other 1 0 value possibilities? 

RFC 1349 refer to this Issue and states that "although the semantfcs of values other than the five 
listed above are not defined by this memo, they are perfectly legal TOS. values, and hosts and 
routers must not preclude their use in any way... "A host or a router need not make any 
distinction between TOS values who's semantics are defined by this memo and those that are 
nor. 



" RFC 791 t Internet Protocol, http://www.letf.Qrn/rfc/rfc791.txt 

37 RFC 1349 - Type of Service In the Internet Protocol Suite, hrta^AvvvwJetf,oTQ/rfc^fcl349.txL 
55 RFC 1455 - Physical Unk Security Type of Service, httix7/wwwJetf.o rQWc/rfci455.tad. 
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The last field, the "MSZ* (must be zero), is unused and must be zero. Routers and hosts ignore 
this last field. This field Is 1 bit long. 

Combining Type-of-Service flags with the different prioritization values, dictates very explicit types 
of behavior with certain types of data. 

Please note the not all TCP/IP implementations would use this values (nor offer a mechanism for 
setting those values) and some will not handle datagrams which have Type-of-Service and/or 
Precedence values other than the defaults, differently. 

6.5 Precedence Bits Echoing (Fingerprinting Microsoft Windows 2000, ULTRIX, 
HPUX 11.0&KU0, OpenVMS and more) 

The precedence bits behavior Is a problem. RFC 1 122, which defines the requirements for 
Internet Hosts, does not outline the way to handle the Precedence Bits with ICMP* The RFC only 
statement about the Precedence Bits fs: 

"The Precedence field is Intended for Department of Defense applications of the Internet 
protocols. The use of non-zero values in this field Is outside the scope of this document 
and the IP standard specification. Vendors should consult the Defense Communication 
Agency (DCA) for guidance on the IP Precedence field and Its Implications for other 
protocol layers. However, vendors should note that the use of precedence will most likely 
require that Its value be passed between protocol layers in just the same way as the TOS 
field Is passed". 

This does not give us something to work with. 

RFC 1B12 r Requirements for IP version 4 routers state that: 

"An ICMP reply message MUST have Its IP Precedence field set to the value as the IP 
Precedence field in the ICMP request that provoked the reply". 

Echoing back the Precedence field value has Its logic, because the TOS field should be echoed 
back with an ICMP Query replies, and both the Precedence field and the TOS field were to 
dictate very explicit types of behavior with certain types of data. 

As you can see we do not have a clear ruling about this issue. I was thinking it might be a ground 
for an operating system fingerprinting method. 

Most operating systems I have checked win behave as the next behavioral example with ADC 4.3. 
With this example an ICMP Echo request is sent which carries a value for the TOS field. 

[root®god£ather precedeace_echo] # /uer/local/bin/eing -c 5 -TOS 12B 

y*y.y-y 

SINGing to y.y.y-y (y-y-y.y) * 16 data bytes 

16 bytes from y»y*y-y? seqt*0 ttl»239 TOS-123 time=5896.472 ma 

16 bytes from y.y.y.y: ae<l-l ttl=239 TOS=128 time-S952 . 071 ms 

16 bytes from y.y*y-y= seq»2 fctl-239 TOS-12B time~6102 • 020 raB 

16 bytes from y-y-y-y: aeq=3 ttl=239 TOS~123 time=G261. 997 ms 

16 bytes from y.y.y*y; seq°4 ttl-239 TOS-12fl time-5842. 726 ms 

y-y.y.y sing statistics 

5 packets transmitted, 5 packets received, 0% packet loss 
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round-trip min/avg/max » 5842.726/6011,057/6261.997 ma 
[root^godf ather precedence_echol # 

The tcpdump trace: 

21:02:53.241666 pppO ? x.x.x.x > y.y.y.y: icropr echo revest [tos 0x80] 
(ttl 255, id 13170) 

4580 0024 3372 0000 f f 01 619c xxXX XXXX 

yyyy yyyy osoo c27b 6f os oooo dd9? 0d3a 

d8af 0300 

21:02:59,134297 pppO < y.y.y.y > x.x.x.x: icmp: echo reply [toe 0x80] 
(ttl 239, id 40656) 

4530 0024 9ed0 00O0 efOl 063e yyyy yyyy 
xxxx xxxx 0000 ca78. 6f05 0000 dd97 0d3a 
dfiaf 03 00 

The Host queried Is using the value used for the ICMP Echo Request with Its ICMP Echo Reply. . 
Some operating systems are the exception. 

The next example is with Microsoft Windows 2000. The same ICMP Echo Request was sent 
[root<e>god£ather precedence_ecbo] # /us r/ local /bin/sing -c 5 -TOS 128 

y-y-y-y 

siNGing to y.y.y.y (y.y.y.y) : is data bytes 
16 bytes from y.y.y-y: seq=0 ttl^lll rrOS=o time=6261 .043 ma 
16 byteB from y.y.y.y: eeq-1 ttlolll TOS=0 timeH6422 .019 ms 
1$ bytes from y.y.y.yt seq=2 ttl»iil TOS«o time»6572 .675 ms 
16 bytes from y.y.y*y: »aq«4 ttl=lll TOS=0 time=S2B2 .022 ms 

y.y.y.y sing statistics — 

5 packets transmitted, S packets received, 20% packet loss 
round- trip min/avg/max * 6261,043/6384 .440/6572. fi75 ms 
[root®godfather precedence_echo] # 

The tcpdump trace; 

20:13;36. 717070 pppO > x.x.x.x > y.y.y.y; icmp: echo request [toa 0X80] 
(ttl 255, id 13170} 

4580 0024 3372 0000 ££01 d95d XXXX xxxx 

yyyy yyyy 0800 d£43 C304 0000 5O0C 0d3a 

edfO OaOO 

20?13:42. 974295 pppO < y.y.y.y > x.x.x.x: icmp: echo reply (ttl 111, id 
26133) 

4500 0024 6615 0000 6f01 373b yyyy yyyy 
xxxx XXXX 0000 e743 c304 0000 508C 0d3a 
edfO OaOO 

The ICMP Echo Reply will not use the value assigned to the Precedence Bits with the ICMP Echo 
Request 

Which operating systems share this behavioral pattern? Microsoft Windows 2000 Family, and 
ULTRIX. 
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Differentiating between Microsoft Windows 2000 and Utorix is easily achieved if we examine the 
IP TTL field value. With ULTRIX the vaJue assigned to the ICMP Echo reply will be 255, with 
Microsoft Windows 2000 It will be 1 28. 



Another interesting case is with HPUX 11,0. Lets examine the trace and logs: 
[rootagodfather precederice_jacho3 # /usr/local/bin/aing -c 2 -TOS 128 

yyyy 

siting to y.y.y.y (y-y.y.y) : 16 data bytee 

16 bytea from y.y.y.y; seq^O ttl=242 TOS=123 time=639.274 ms 
16 bytes from y.y*y,y; SOC^l DFi ttl-242 TOS-0 time=310 .427 ms 

y.y.y.y sing statistics 

2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/majc - 310.427/474.850/639.274 me 

The first reply from the HPUX machine echoed back the TOS field value we were using wtth the 
ICMP Echo Request. But what have happened between the first and the second reply? 

□o?35:09, 315260 pppo > x.x.x.x > y.y-y.y: icmp: echo request [too oxbo] 

{ttl 255, id 13170) 

4580 0024 3372 0000 ffOl 4bdX 30QOC 

yyyy yyyy oaoo asfo db3c oooo 9dc9. od3a 

56cf 0400 

00:35:09.944274 pppo < y.y.y.y > x.x.x.x: icmp: echo request (PF) (ttl 
242, id 22417) 
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Th& first request was sent, as an Instant reply the HPUX 1 1.0 machine started its PMTU 
discovery process with ICMP Echo Requests and sent an ICMP Echo Request 1500 bytes long 39 . 



00:35:09.944355 pppO > x.X.x.X > y-y.y.ys icmps echo reply (ttl 255, id 
14194) 
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For an explanation about the HPUX 1 1 .0 PMTU process using ICMP Echo Requests please sea section 6.2. 
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0000 0000 0000 0000 0000 0000 

00:35:09.954282 pppO «: y.y.y.y * x.x.x.x: icmp: echo reply [toa 0x80] 
(ttl 242, id 22418) 

4580 0024 5792 0000 f201 34bl yyyy yyyy 
xxxx xxxx 0000 lefO db3c 0000 9dc9 0d3a 
56cf 0400 



The ICMP Echo Reply received from the HPUX 11*0 machine for the ICMP Echo Request 
echoed back the TOS flew value* 

Another ICMP Echo Request was sent with TOS field value of 0x80 hex: 

00:35:10.314321 pppO > x.x*x*x > y.y*y>y= icrap: echo request [toa 0x80] 
(ttl 255, id 13170) 

4560 0024 3372 0000 ffOl 4bdl xxxx xxxx 
yyyy yyyy OSOO b7f3 db3c OlOO 9ec9 0d3a 
b3cb 0400 

00:35:10*624275 pppO < y.y.y.y > x.x.x.x: icmp: echo reply (DP) (ttl 
242 , id 22419) 

4500 0024 5793 4000 f201 f52f yyyy yyyy 
XXXX XXXX 0000 bff3 db3c. 0100 $&c9 0d3a 
b3cb 0400 



The ICMP Echo Reply received did not echo back the TOS field value, and set the DF bit. The 
PMTU discovery process finished its Initial stages and went to regular operation. From now on 
the ICMP Echo Replies did not echo the TOS field value. 

; 

This gives us the ability to track down HPUX 11.0 (and 10.30) machines when they are using the 
PMTU Discovery process, - 

6.5.1 Changed Pattern with other ICMP Query Message Types 

We can Identify change of pattern with OpenVMS, Windows 98, 98SE, and ME. With ICMP Echo 
replies they all would echo back the TOS field value, but with ICMP Tlmestamp replies'they will 
change the behavior and send back 0x000. Since OpenVMS use 255 as Ms IP TTL field value, 
and the Microsoft Windows based machines use 1 28, we can differentiate between them and 
isolate OpenVMS, and the Microsoft based OSs. 

Further distinction between the Microsoft operating systems can be achieved if we will query 
them with ICMP Address Mask request, which only Microsoft Windows 9Q/98SH will answer for. 
The Mtcrosoft Windows ME will not reply, enabling us to Identify it. 
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ICMP Echo Request 
Precedence Bite 



Reply with 
Precedence 
Bits 1*0 




other OS's 



® tCMP Time stamp Request 
Precedence Bits t=0 



Reply with 
Precedence 
Blta=Q 



Windows 2000 Family 
UTtrf^ 



Reply with 
Precedence 
BHat«0 



Other OS's 



Reply with 
Precedence 

BIIb-O 



TTL=255 



Ultrtx 



TTL=123 



Windows2000 Family 



Windows 08/98SE/ME ' 
Open VMS 
ULTRtX (Identified already) 
Microsoft Windows 2000 Family 
(Idonllffod Already) 



TTL=?$5 



TTL=128 



OpenVMS 



Windows 9B7S3SE/IVIIE 

©ICMP Address Mask Request 



No Reply 



Reply 



Windows ME 



Windows 96/90SE 



Diagram 6: An example for a way to fingerprint Microsoft Windows 2000. Ultrix, HPUX 1 1 .0 & 1 0.30, 
OpenVMS, Microsoft Windows ME, and rVfcrosoft Windows 98/98SE based machines with ICMP Query 
messages with the Precedence Bits field 1=0 



Operating System . " 


Information 
Request 
With 
freeedence.1-0 


Time Stamp 
. Request 
With Preeedeneef=0 


' • Address Mask 

■ Request • "\ 
Wl.uYPrecedeneel=0 


Echo Request 
Wltti P*TBcadencel=0 

■ . - , 


Debton GNU/ LINUX 2_2, 
Kernel 2.4 test 2 
Redhat LINUX 6.2 Kernel 
2.2.14 


Not Answering 
Not Answering 


1=0X00 
1=0x00 


Not Answarino 
Not Answering 


1=0x00 
1=0x00 


FreeBS04.0 
Free BSD 4.1,1 
OpenBSD 2.7 
OpenBSD Z.B 
NfltBSD 

BSDI BSD/OS 4.0 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00. 

1=0x00 
1=0x00 
1=0x00 
>0x00 
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OpereUagSystom 


Information : 

With' ' 
PrecodencBl=0 : 


! Time Stamp 
Request ' 
,WUh PrecedencelK) 

:.!•-:•• ■> 


Address Mask 
Request ... 
wim Precedence!^ 


: Echo Request 
With Precedence!^ 


BSDI BSD/OS 3.1 


Not Answering 




Not Answering 


1=0x00 


Solaris 2^,1 
Solaris 2.6 
Solaris 2.7 
Solaris 2.B 


Not Implemented 
Not Implemented 
Not Implemented 
Not Imptomonted 


IKW50 
1=0x00 
1=0x00 


1=0x00 
1=0x00 
1=0x00 


1=0x00 
1=0x00 
!=0x00 


HP-UX v1 0,20 
HP-UX v1 1.0 


Not Answering 


Not Answering 


Not Answering 
1^0x00 -> 0x00 


1=0x00 -> 0x00 


Compaq Tru64v5.0 


1=0X00 


!=6x00 


Not Answering 


1-0x00 


AIX4.3 
AIX 4.2.1 
AN4.1 ' 
A1X3.2 


1=0x00 
1=0x00 
1=0x00 
•: !=0x00 


1=0x00 
1=0x00 
1=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 
1=0x00 
1^0x00 
1=0x00- 


ULTRIX4^-4.5 


0x00 


0x00 


0x00 


0x00 ! 


OpenVMS V7.1-2 


0X00 


0x00 


0x00 


1=0x00 


Windows 9S 
Windows 96 
Windows 96 SE 
Windows ME- 
WbTdowsNT4WRKS SP 3 
Windows NT 4 WRKS SP 
6a 

Windows NT 4 Server SP4 
Windows 2000 professional 
Windows 2000 Sen/or 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 

0x00 

0x00 
Not Answering 
Not Answering 


0x00 
0x00 
Not Answering 

Not Answering 


1=0x00 
1=0x00 
1=0x00 
1=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
0x00 
0x00 


NotAnswenng 
Not Answering 
Not Answering 


1=0x00 
0x00 
0x00 



Tab!© 10: ICMP Queiy Message Types with Precedence Bits 1 = 0 



6.6 TOSing OSs out of the Window / "TOS Echoing" (Fingerprinting Microsoft 
Windows 200Q) 

6.6.1 The use of the Type-of-Serv|ce field with the Internet Control Message Protocol 
RFC 1349 also define the usage of the Type-of-Servlce fieW with the ICMP messages. It 
distinguishes between ICMP error messages (Destination Unreachable, Source Quench, 
Redirect, Time Exceeded, and ParameterProblem), ICMP query messages (Echo, Router 
Solicitation, Timestamp, Information request, Address Mask request) and ICMP reply messages 
(Echo reply, Router Advertisement Timestamp reply, Information reply, Address Mask reply). 

Simple rules are defined: 

■ An ICMP error message Is always sent with the default TOS (0x00) 

• An ICMP request message may be sent with any value In the TOS field. 'A mechanism to 
allow the user to specify the TOS value to be used would be a useful feature In many 
applications that generate ICMP request messages"* 0 . 



40 RFC 1349 - Typo of Service In the Internet Protocol Sutto, httor//www.brf-om/rfc/rfo1 349Jxt. 
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The RFC further specify that although ICMP request messages are normally sent with the 
default TOS, there are sometimes good reasons why they would be sent with some other 
TOS value, 

■ An ICMP reply message is sent with the same value in the TOS field as was used in the 
corresponding ICMP request message. 



Using this logic I have decided to check if certain operating systems react correctly to an ICMP 
Query messages with a Type-of-Service field value, which is different than the default (0x00). 

The check out was produced with all ICMP query message types sent with a Type-of-Service field 
set to a known value, than set to an unknown value (the term known and unknown are Used here 
because I was not experimenting with non-legrt values, and since any value may be sent Inside 
this field). 

The following example is an ICMP Echo request sent to my FreeBSD 4.0 machine with the TOS 
field equals an 3 hex value, which is a regit TOS value. The tool used here is SING 41 : 



[rootOgodfather bin]# ./sing -echo -TOS 8 IP_Address 
SXNGino; to IPjVtfdress (IP^Addreaa) : IS data bytes 

16 bytes from IP_AddreB3i~icmp_seq-2 fctl«243 TOS=B time=260.043 raa 
16 bytes from IP_Address: icmp_aeq^3 ttl=243 TOfl=8 time=lS0 * Oil ms 
16 bytes from IP^AddresB: icTnp~3 e 3" 4 ttl-243 TOS=8 time*24Q.240 ms 
16 bytes from IPJfcddresa: icmp~seq=5 ttl~243 TOS-8 time-260 . 037 ms 
IS bytes from. IP_Address: icmp,jseq=;6" ttl=243 TOS=B time=290 . 033 ms 

XP__Addrees sing statistics 

7 packets transmitted, 5 packets received, 28* packet lose 
round-trip rnin/avg/raax = 180.011/246,073/590.033 ms 
Iroot®god£ather bin]# 



The tepdump trace; 



17:23:46.605297 if 4 5. x.x,x,x > y.y^y.y: lamps echo request [fcoa OxB] 
<ttl 255, id 13170) 

4508 0024 3372 0000 ff 01 60e4 xxxx xxxx 

yyyy yyyy osoo oe9a deo4 osoo f2ea bc39 

553c 0900 

17:23:46.895255 if 4 < y,y,y,y > x.x.X.X: icmp; echo reply [too 0x8] 
(ttl 243, id SB832) 

4508 0024 e5d0 0000 f3 01 baBS yyyy yyyy 
xxxx xxxx 0000 169a 4604 0600 f2ea bC39 
553C 0900 



This Is the second test I have produced, sending ICMP Echo request with the Type-of-Servlce 
field set to a 10 Hex value, a value that Is not a known Type-of-ServIce value: 



SING has the ability to monitor for any replies and than print the received TOS value. I find this option very useful, and 
lhank the author for embedcKng into function, a3 1 requested. 
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Irootogodfather bin)# ./sing -echo -TQ0 10 IP_Address 
SINGing to IP_Address {IP_Address) z 16 data bytes 

16 bytes from lP_Addreas :~icmp_seq=;0 ttl^243 TO3»10 time-197.933 ma 
16 bytes from IP_Addrese : icrap_eeq=»l ttln243 TOS-10 timea340.04B ms 
16 bytes from IP_Address-, icmp_seq=2 ttl=243 TOS=*10 titne=25 0.025 ms 
16 bytes from IP_Address: icrap_Beq-3. ttl=*243 TOS-10 time»230 . 019 ma 
16 bytes from IPJfcddress: icmp_seq=»4 ttl=243 TOS^IO time=270 .017 ms 
16 bytes from IP_Addxese: icmp_8eq=5 ttln243 TOSolO time-270 . 017 ms 
16 bytes from lP_Addrea,a: icmp~s e q iB G ttl=243 TAa«10 time=260 ♦ 021 ma 

IP_Addresa sing statiptics . 

7 packets transmitted, 7 packets received, 0% packet loss 
round-trip rain/avg/max - 197.933/259.726/340.048 ms 

The tcpdump trace: 



17:24:36.155299 if 4 > Y-Y-y-y > x.x.x.x: icmp : echo request [fcos 

Oxa,ECT] (ttl 255, id 13170) 

4S0a 0024 3372. 0000 f fOl 60e2 yyyy yyyy 
xxxx xxxx 0800 af77 d904 0600 24eb bc3$ 
865e D20O 

17:24:36.415254 if 4 < x,x.x.x > y.y.y.y: icmp: echo reply [too 

Ox*,ECT] (ttl 243, id 65031) 

450a 0024 fe07 0000 f301 a24c XxXx xxxx 
yyyy yyyy 0000 b777 d904 0600 24eb bc39 
865e 0200 



As It can be seen from the tcpdump trace, the ICMP Echo reply messages have maintained the 
Type-of-Service value as was used in the corresponding ICMP request message. 

FreeBSD 4.0 does not respond to ICMP Information request, or to ICMP Address Mask requests* 
I had to verify with ICMP Tlmestamp requests with the same Type-of-Servlce values as with the 
previous ICMP Echo requests that this behavior is produced with ICMP Tlmestamp request and 
replies as well. 

Again the tool I have used Is SING: 

[root®godfather bin]# ./sing -tetamp -TOS 8 lP_Address 
SINGing to IP_Address (IP__Address) : 20 data bytes 
20 bytes from IP_Address? icmp_eeq=0 ttl=»243 TOS=8 diff =6832668 
20 bytes from IP_AddreaS: icmp_seq«l ttl=243 TOS-B di££-G832403 
20 bytes from IP_Address: icrap_seq=>2 ttl=243 T0S=8 diff =6832633 
20 bytes from IP_Address: icmp~seq.=3 ttl-243 TOS-B diff -6832605 
20 bytes from IP_Addresa s icmp~seq«4 ttl=243 T03=»8 diff -6832431 

— - IP_Address sing statistics 

5 packets transmitted, 5 packets received, 0* packet loss 
[rootagodfather bin]# 
The tcpdump trace: 

17:25:00.455295 if 4 > x.x.x.x > y-y.y.y: icmpj time stamp request 
[tos 0x8] (ttl 255, id 13170) 

4508 0028 3372 0000 ffOl 60e0 XXXX XXXX 
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yyyy yyyy OdOO 345b Sd04 0400 031B daB7 

0000 0000 0000 0000 
17:26:00. 7SS254 if 4 < y.y.y.y > x.x.x.x: icmp; time stamp reply [too 
0x8] <ttl 243, id 5B67) 

4508 0028 X6eb 0000 £301 B9G7 yyyy yyyy 

sooex xxxx OeOO f4ec dd04 0400 0318 da67 

0380 lbb7 0380 lbb7 



The second test with TOS field value set to 1 0 Hex value: 

[root©godfather bi»]# ,/sing -tstamp -TOS 10- XP_Addres8 
SINGing to IP_Addresa (IP_Address) : 20 data bytes 

20 bytes from IP_Addreas: icmp_aeq-o ttl=243 TOS-10 diff«6766B72 

20 bytes from IP^Address : ictnp_seq=l ttl^243 TOS=10 diff=67$7P59 

20 bytes from iP^Address: icmp~seq-2 ttl-243 TOS*10 diff-6767059 

20 bytes from IP~Address: icmp~seq=3 ttl^.243 TOS-10 dif f -6767063 

20 bytes from IP~AddressY icmp_seq»4 ttl-243 TOS=10 dif f -6766892 

20 bytes from IP_Address: icmp_seq=5 ttl^243 TOS-10 diff =6766037 

20 bytes from IP^AddreSs: icmp^seqog ttl-243 TOS=10 diff>6766873 

20 bytes from IP_Address: icinp~seq=7 ttl=*243 TOS=10 ditje-6767057 
A C *" " 

194,47.250.37 sing statistics 

9 packets transmitted, 9 packets received, 0% packet lose 
[rootogodfather bin] # 

The tcpdurnp trace: 

17:25;42.548597 if 4 > X.X.x.x > Y»y-y.Y = icmp: time stamp request 
[toa Oaca,ECT] (ttl 255, id 13170) . 

450a 0028 3372 0000 ££01 60de xxxx 3onoc 

yyyy yyyy odoo 7f4e dc04 oooo 03ia 9494 
0000 0000 0000 O00P 

17;25:42. 795254 if 4 < y.y.y.Y > 3C.X*X,x: icmp: time stamp reply [tOS 
0xa,ECTJ (ttl 243, id 3519) 

450a 0028 odb£ oooo f3oi 9291 yyyy yyyy 

MtXX XXXX OeOO Cbf6 dc04 0000 0318 9494 
037f d5ac 037f dSac 



The same behavior was produced. The ICMP Timestamp replies were sent with the TOS field 
value equals the TOS filed value of the ICMP Tlmestamp requests. 

Ok. I was curious again. I Imagined that the Microsoft Windows Implementation of the things 
might he a little different. 

When | was examining ICMP Echo requests I noticed something is wrong with Microsoft 

[root@god£ather bin]# ./sing -echo -TOS 8 Host_Address 
SINGing to Host_AddresS (IP_Addres9) ; 16 data bytes 
15 bytes from IPJVddressi icrap_seq=0 ttl=113 TOS-0 time=278-8l3 ma 
IS bytes from IPJVddressi icmp_seq=»l ttl=113 TOSoO time«239.935 ms 

n 
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16 bytes from IP_Addi:ess: icmp_seq»2 ttloll3 TOS=0 time=249 . 937 m3 
16 bytes from IP_Address: icrap_eeq^3 ttl«113 TOS-0 tiTnea229 . 962 ms 
IS bytes from IP_Addreiss: icrcp_J3eq«4 ttl-113 TOSaO time^249 . 951 ms 

Host_Addjrees sing statistics 

5 packets transmitted, 5 packets received, 0% packet loss 
round-trip min/avg/max = 229.952/249.720/278.813 ms 
[rootagodfather bin]# 



The tcpdump trace: 



1^:28:08.346537 if 4 > x.x.x.x > y.y.y.y: icmp: echo request [tos 0x8] 
(ttl 255, id 13170) 

4508 0024 3372 0000 ££01 083f xxxx. xxxx 
yyyy yyyy 0800 cdSb e704 0000 fSeb bc39 
8949 0500 . 

I7=28i08. 625250 i£ 4 < y.y-y.y > x,x.x.x= icmp: echo reply (ttl 113, 
id 12951) 

4500 0024 3297 0000 7101 9722 yyyy yyyy 
xxxx xxxx 0000 d58b e704 0000 f$eb bc39 
8949 0500 



Oops! Some one zero out my Typs-of-Service field! 

Before I would let you know who of all Microsoft Windows operating systems did that, | am going 
to list the Microsoft operating systems who behave correctly ~ Microsoft Windows 98/SE/ME, 
Microsoft Windows NT 4 Workstation SP3, Microsoft Windows NT 4 Server SP4, Microsoft 
Windows NT 4 Workstation SPBa. 

The Microsoft Windows 2000 family (Professional, Server, Advanced Server) zero out this field on 
the ICMP Echo reply. 

Is this makes those Microsoft Windows 2000 machines Identified easily and uniquely? 
99.9% yes. The other 0.01 % belongs to Ultrix & Novel Netware. 

From the operating systems | have checked (Linux Kernel 2,2.x, Linux Kerne! 2.4 test 2/4/5, 
FreeBSD 4.0 & 4.1, OpenBSD 2.6 & 2.7, NetBSD 1.4*2, SUN Solaris 2.7 & 2,8, Compaq Tru64 
UNIX 5,0. AIX 4*1 «. 3.2, OpehVMS v7.2, Irix 6.5.3 & 6.5.8. Ultrix 4,2-4.5, Microsoft Windows 
98/SE/ME, Microsoft Windows NT 4 Workstation & Server with various service packs, Microsoft 
Window® 2000 Professional, Server & Advanced Server) only Ultrix & Novell Netware behaved 
like the Microsoft Windows 2000 machines. 



How can we distinguish between those? 

First, there are much fewer Ultrix and Novell operating systems based machines out there than 
Microsoft's Windows 2000 based machines (I see your faces - not convincing enough). 

The fast track fn distinguishing between Ultrix, Novell Netware and Microsoft Windows 2000 is a 
Simple one. - By looking at the IP TTL field value within the ICMP Echo replies. Microsoft 
Windows 2000 famOy of operating systems use 128 as their default IP TTL field value in ICMP 
ECHO replies while Ultrix uses 255. The problem Is Novell uses the same value for Its IP TTL 
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Field value as Microsoft Windows 2G00 based machines (For more Information about the IP TTL 
field value see section 6.3 - .The IP Tlme-to-Uve Field Value with ICMP 1 ). 

As a next step we can use various types of queries in order to distinguish between the Novell 
Netware based machines, to the Microsoft Windows 2000 based machines. One of those steps 
can be an ICMP Tlmestamp request sent to the "suspicious" machines. No reply from one of the 
machines will indicate it may be using Novell Netware, a reply from a machine will Indicate it Is 
using one of Microsoft Windows 2000 operating system family product More sophisticated ICMP 
queries could replace the one I have introduced. 



Other ICMP query message types help us to Identify a unique group of Microsoft operating 
systems. As a rule all operating systems except the named Microsoft windows operating systems 
here, maintain a single behavior regarding the Type-of-Servlce field. All would maintain the same 
values with different types of ICMP requests. But, again, Microsoft have some of the Top" people 
understanding TCP/IP to the degree we humon3 do not understand. . 



ICMP Echo ftoquett 
TOSW) 




OtherOS's 



© 

tosj-o 



Repry with 
TOSJ«0 



OthorOS'a 





Windows 2000 Family 
Novell Kffttwnm 



TTL=265 



Uttrix 



ULTFBX (fdflMJflftd AJrtady) 
W!nd?wv20DO family (Identified 



® 



TTL- 128 



Wndowi2P0D Family 
Novell Netware 

tCMPTImostamp Request 





Diagram 7: An example for a way to fingerprint Windows 2000, tutrix, and Novell Netware based machines 
with ICMP Query messages with thoTOS bits field 1-0 



We have the following Microsoft operating systems zero out (0x00) the Type-of-Servlce field with 
the replies for ICMP Timestamp requests: Microsoft Windows 98/98SE/ME. Microsoft Windows 
2000 machines would zero out the TOS field with ICMP Tlmestamp replies as well. 



This means that Microsoft Windows 98/98SE/ME would not zero out the Type-of-Servlce field 
value with ICMP Echo requests but will do so with ICMP Tlmestamp requests. 
With the introduced fingerprinting methods In this section we got a way to fingerprint Microsoft 
Windows 2000, Ultrix, and Novel Netware machines from the rest of the operating systems world. 
We have a way to distinguish Microsoft Windows 98/9BSE/ME (and to set those apart) from the 
rest of the operating system world, as well. 
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Operating System 


Information 
- Request - ' 
WlthTOSl*<W)0 


Time Stamp Request 
' WHn TOSI=0x00 


Address Mask 

Request 
WithTOSNOxbO • 


Echo Request . 
WKrtTOSI=0x00 


Deblan GNU/ LINUX 2*2* 
Kernel 2.4 test 2 
Reonat UNUX U.2 Kernel 


Not Answering 
Not Answering 


1=0x00 
1=0X00 


Not Answering- 
Not Answering 


1=0x00 

1=fWYI 

J^vXUU 


FreeBSD4.0 
FreeBSD3.4 . 
Open BSD 2.7. 
OpenB5D2.6 
NetBSD 

BSD1 BSD/OS 4.0 
BSD1 BSD/OS 3.1 


Not Answering 
Not Answering 
Not Answarlng 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 

1*0x00 
|=OxQ0 
1=0x00 
1=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 

1=0x00 . 
1=0x00 
1=0x00 
I "0x00 
1=0x00 


Sotarfe 2.5.1 
SoterteZB 
Solaris 2.7 
Solaris 2.B 


Mot Implemented 
Not implemented 
Not Implemented 
Not Implemented 


t"0x00 
1=0x00 


1=0x00 
1=0x00 


1=0*00 
I »0x00 


HP-UX v 10.20 
HP-UX v1 1.0 


Not Answering 


Not Answering 


Not Answering 
1^0x00 


1=0x00 


Compaq T|UB4 V5.Q 




l=D*DO 


Not Answering 


1=0x00 


MX $-55.3 
Irix 6.5.8 


Not Answering 
Not Answering 


1=0x00 
1-0x00 


Not Answering 
Not Answering 


1-0x00 

1=0x00 


AIX4.1 
MX 3^ 




[=CbcDO 
1*0x00 


Not Answering 
Not Answering 


1=0x00 
1=0x00 


ULTRIX4^4.5 




0x00 


0x00 


0x00 


OpenVMS v7.1-2 




l=i 0x00 


1=0x00 


1=0x00 


NoveD Netware 5.1 SP1 
Novett Netware 5.0 
Nave* Netware 3.12 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Anc waring 
Not Answering 


Not Answering 
Not Answering 
- Not Answering 


0x00 
0x00 
0x00 


Windows 95 
Windows 98 
Windows 98 SE 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server 5P4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
. Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 

0x00 

0x00 
Not Answering 
Not Answering 
Not Answering 

0x00- 

0x00 


0x00 

Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 
1=0x00 
1=0x00 
.1=0x00 
1=0x00 
1=0x00 
0x00 
0x00 



Table 1 1 : ICMP Query Message Types with TOS! = 0 



6.7 Using thfc TOS Byte's Unused Bit (Fingerprinting Microsoft Windows 2000 f 
ULTRCX and more) 

RFC 1349 states that the last field of the TOS byte, the "MBZ" (must be zero), is unused and 
must be zero. The RFC also states that routers and hosts Ignore the value of this bit 

This is the only statement about the unused bit iri the TOS Byte in the RFCs. The RFC states: 
"The originator of a datagram sets this field to Zero - . 
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Obviously it was meant that this field would be always zero. But what will happen If we would set 
this bit With our ICMP Echo Requests? Will this bit be zero out on reply or wJII It be echoed back? 

Only with ICMP Echo requests we can have a clear Identification of OSs, 

The next example is an ICMP Echo Request sent with the TOS bit In the TOS Byte set, targeting 
a freeBSD 4.1.1 machine: 

[root®godfather /root]# /usr/ local /bin/sing -c 2 -TOS 1 y.y.y.y 
SlNGing to y-y.y,y (y.y.y.y) : 16 data bytes 
XS bytes from y.y.y.y: seq*0 ttl~233 TOS-1 time.330.4l6l ms 
16 bytes from y.y.y.y: seq-1 ttl=333 TOS-1 tirae=723 .300 ms 

y.y.y.y g^ng Statistics 

2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/max a 330 .461/526 .830/723 .300 ms 
[rootogodfatiier /root]# 

Echoing back the Unused bit in the TOS Byte represents the behavior of most of the operating 
systems I have checked this method against 

Which operating systems are the exceptions? 

The next example is with Microsoft Windows 2000 as the targeted machine: 
lroot<&godfafcher precedence_echo] # /usr/ local/bin/sing -c 2 -Tos 1 

y*y*y-y 

SXNGing to y.y.y.y (y.y.y.y) j 16 data bytes 

16 bytes from y>y*y.y: seq»o ttl=lll TOS=o time»299.l8S ms 

16 bytes from y.y.y.y: seq=l ttl=lll TOS-0 timB-280,321 me 

y.y.y.y sing statistics 

2 packets transmitted, % packets received, 0% packet loas 
round-trip min/avg/max - 290 .321/289.755/299.188 ms 
[rootogodfather precedence_echo] # 

The tcpdump trace: 

00:17:01.765492 pppO > x.x.x.x > y.y.y.y: icrapi echo request [toa 0x1 J 
(ttl 255, id 13170) 

4501' 0024 3372 0000 ftoi dB2b xxxx xxxx 

yyyy yyyy osoo fois 7a3c dooo sdcs od3a 

17ae ObOO 

00:17:02.064204 pppO < y*y*y.y > x.x.x.x: icmp; echo reply {ttl lli f id 
29961) 

4500 0024 7509 oooo '6foi 2696 yyyy yyyy 

xxxx xxxx 0000 f815 7a3c 0000 5dc5 0d3a 
l7ae ObOO 
Another OS that behaves the same is ULTRIX: 

Eroot®god£ather precedence_echo] # /usr/local /bin/ sing -c 2 -TOS 1. 

y-y-y.y 

SlNGing to y.y.y.y Cy.y,y.y) : 16 data bytes 

16 bytes from y.y.y.y: seq=o ttl»237 TOS«0 time~371*776 ms 

y.y.y.y sing statistics 

2 packets transmitted, 1 packets received, 50% packet loss 
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round-trip rcin/avg/max - 371, 776/371. 776/371*776 ms 
[rootflgodf at her precedence_echo] # 

We will use, again, the IP TTL field value to differentiate between the two operating systems. 
6.7.1 Changed Pattern with Replies for Different ICMP Query Types 

We have a changed pattern with Microsoft Windows 98/98SE/ME when using other ICMP Query 
message types other than ICMP Echo Request. Instead of echoing this field back, they win zero 
out this field with their replies. 



ICMP Echo Request 
Unused Bit "1 



Reply with 
Unused Bit !°0 




Other OS'e 



ICMP Time stamp Request 
Unused Bit =1 



Reply with 
Unusod Bit l=D 



Other OS's 



Reply with 
Unused Bit =0 



Reply uriDi 
v Unused Bit O 



Windows 2000 Family 



TTL»2S6 



UllHx 



Window398/9&SE/ME 
OpefiVMS 
ULTWX(Wentlfled Already) 
Windows 2000 Kamliy (Identified" Already) 



TTL-12B 



Windows 2000 Family 



TTL-255 



TTL=t2B " 



OpenVMS 



Windows 96/983E/WE 

®.c, 



MP Address Mask Request 



No Reply 



Reply 



Windows MB 



Windows BS/B8SE 



Diagram 8: An example for a way to fingerprint operating systems using the unused bit in the TOS Byte 

echoing method 

Further distinction between the Microsoft operating systems can be achieved If we will query 
them with ICMP Address Mask request, which only Microsoft Windows 98/98SE will answer for. 
The Microsoft Windows MB wlU not reply, enabling us to identify It 



77 

Copyright © Ofir Aridn, 2000-2001 

httpVAwwtfw.BVS^ecuritv-coTn 



PAGE 131/209 * RCVD AT 7/1/2004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DNiS:7469694 1 CSID:9497609502 1 DURATION (mm-ss):5746 



Jun-30-2004 09:37pm From-KNOBBE MARTENS OLSON BEAR 949 7609502 T-7QZ P. 028/105 F-610 

■ O , O ' "" '': 

ICMP Usago Jn Scanning 
. Version 2.5 



Operating System 


; Information 
"J ' .Request : 
With Ufnused»i. 


Time Stamp Request 
. With UnusedTl 


Address Mask 
: Request ■'■ 
V . Wfth Uriuseo^l 


Echo Request • 
With Unused»1 


Oeblan GNU7 LINUX 2.2, 
Kernel 2.4 test 2 
Redhat LINUX 52 Kernel 
£2.14 


Not Answering 
Not Answering 


0x1 
0x1 


. Not Answering 
• Not Answering 


0X1 ■ 
0x1 


rteeBSD4.0 
rVeeBSD 4.1.1 
OpenBSD 2.7 
OpendSD 2.6 
NetBSD 

BSDI BSD/OS 4.0 
BSDI BSD/OS 3.1 


Nat Answering 
Not Answering 

Not Answering 
Not Answering 
Not Answering 
Nat Answering 
Not Answering 


0x1 
0x1 


Not Answering 
Not Answering 
. Not Answering 
' Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
0x1 


SglariB 2.5.1 
Solaris 2.6 
Solaris 2.7 
Solaris 2.8 


blol FmrrfG minted 

Not Implemented 
Not bnplQroofilQd 
Not Implemented 


0x1 

* Oxi 

0x1 


0x1 
0x1 
0x1 


0x1* 

0x1 

0x1 


HP-UX vl 0.20 
HP-UX v1 1.0 


Not Answering 


Not Answering 


Not Answering 
0x1 


0x1 


Compaq Tru64 v5.0 


0x1 


0x1 


Not Answering 


0x1 


AIX4.3 
AIX4^.1 
AIX4.1 
AIX3,2 


0x1 
0x1 
0x1 

0x1 


0x1 
0x1 
0x1 
0X1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
0x1 
0x1 
0x1 


ULTR1X4.2-4.5 


0x0 


0x0 


DxO 


0x0 


OpenVMS V7.1-2 


0x1 


0x1 


0x1 


on 


Windows 95 
Windows 98 
Windows 98 SE 
Windows ME 

WlndowaNT4WFlKSSP3 
Windows NT 4 WRKS SP 6* 
Windows NT 4 Server SP4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Aftswaring 
0x0 
0x0 
0x0 

Not Answering 
Not Answering 
Not Answering 

0x0 

0x0 


0x0 
0x0 

Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


0X1 
0x1 
0x1 

0x1 

0x0 
0x0 



Table 12: ICMP Query Message types with the TOS Byte Unused Bit value I = 0 



6.8 Using the Unused (Identifying Sun Solaris a HP-UX 10.30 & 11.0X OS based 
machines) 

RFC 791 defines a three bits field used for various control flags in the IP Header. Bft 0 of this bits 
field 13 the reserved flag, and must be zero according to the RFC. 

What wOl happen if we will decide to break this definition and send our ICMP Query requests with 
this bit set (having the value of one)? 

Sun Solaris & HPUX 1 1.0x (possibly 10.30 as well) will echo back the reserved bit 

This Is a tepdurnp trace describing an ICMP Echo request sent with the reserved Bit set, and the 
ICMP Echo repiy we received echoing the reserved bit. This trace was produced against an HP- 
UX 11 l0 machine: 
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21:31:21.033366 if 4 > y.y.y.y > x.x.x.X: icrap: echo request (ttl 255, 
id 13170) 

4500 0024 3372 sooo ffoi fc8c yyyy yyyy 
xxxx xxxx OBOO Bblb 8603 0000 £32* bd39 
3082 0000 

.21:31:21.317916 if 4 < x,x.x.x > y.y.y^y: icnip: echo reply (ttl 236, 
id 25606) 

4500 0024 6406 3000 ecOl de£8 xxxx xxxx 

yyyy yyyy oooo 3310 aeo3 oooo f&sa bd39 

3082 0000 

The next trace was produced against a Sun Solaris 2.8 machine: 

16*51:37-470995 if 4 > 195.72.167.220 > X.x.x.x; icmp: echo request 
(ttl 255, id 13170) 

4500 0024 3372 8000 ffOl eOel c348 a7dc 
xxxx XXxx 0800 edae 3004 0000 69e3 bc39 
ad2£ 0700 

16:51:37.745254 if 4 < x.x.X.X > 195.72,167,220: icmp: echo reply (DF) 
(ttl 243, id 5465) 

4500 0024 156d cOOO f301 cae6 xxxx xxxx 
c348 a7dc 0000 f5aa 3004 0000 69e3 bc39 
ad2f 0700 

If we examine these traces closely we can Identify a distinction between them. The DF bit is set 
with the Sun Solaris ICMP Query reply and not with the HP-UX 1 1.0 OS reply. 

If you recall from the *DF Bit Playground" section Sun Solaris would set the DF bit by default with 
all Its ICMP Query replies, HP-UX 10.30, and 11. Ox operating systems would JnlHate. by default, a 
proprietary method in Older to determine the PMTU using ICMP Echo requests. After the PMTU 
is determined the following ICMP Query replies would have the DF bit set in the IP Header. 

tf we are using Only one datagram than in most cases we can distinguish between Sun Solaris 
and HP4JX 1 0.30, and 1 1 .Ox operating systems since the DF bit will not be set (and if the PMTU 
Is not already determine), 

All ICMP Query replies on the same operating system use the same pattern (either echo the 
reserved bit with ail replies or not). This enable us to use another ICMP Query message type for 
this fingerprinting method. If we send an ICMP Address Mask request with the reserved bit set, 
the result a Sun Solaris 2,fl machine will produce will be something like the next trace; 

IB :39:32.262869 if 4 > y.y*y.y > x.x.x.x : icmp: address mask request 

(ttl 255, id 13170) 

. 4500 0020 3372 8000 ffOl el2e yyyy yyyy 

xxxx xxxx 1^00 aOfb 4e04 0000 0000 0000 
18:39:32.561373 if 4 . < x.x,x,x > y.y.y.y: icrap: address mask is 
OxffffffOO (DF) (ttl 243 , Id 51792) 

4500 0020 ca50 cOOO f30l 1650 XXXX XXXX 

yyyy yyyy 1200 aofa 4e04 0000 fff f ff 00 

We win have both the reserved bit and the DF bit set on the ICMP Address Mask reply, a unique 
pattern Sun Solaris machines have with ICMP Query replies. 

This operating system fingerprinting method enables us to identify and distinguish between Sun 
Solaris, and HP-UX 10.30 &11.0x operating systems to the other operating systems. 
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LSt^^l^^H ^" a ' ! Uthor 0f SING ' to inc ^°rate the ability to set the reserved 
brt wtth his tool. Mredo has introduced the -U option along with the ability to identify if this bit Is 
set on the reply fif any) we get, with the latest version of SING: 

[root@godfather bin]# ./sing -mask -U IP_Address 
SINGIng to IP_Address (IP_Address): 12 data bytes 

12 bytes from IP_Address: fcmp_seq=0 RFI DFI ttl=243 TOS=0 mask=255.255.255 0 
12 bytes from IP_Address; Icmp_seq=1 RFI DFI TOS=0 mask=255.255^55 0 

12 bytes from IP_Address: lcmp,seq=2 RFI DFI ttt=243 TOS=0 mask=255.255.25S.O 
12 bytes from IP^Address: icmp_SBq=3 RFI DFI tU=243 TOS=0 mask=255.255 255 0 
12 bytes from lP_Address: icmp_seq=4 RFI DF! ttl=243 TOS=0 mask=255.25S.255 0 
— IP^. Address sing statistics — 

5 packets transmitted, 5 packets received, 0% packet loss 
[root@godfather bin]# 

This method was tested against Linux Kernel 2.4 test 2,4,5,6; Linux Kernel 2.2.x; FreeBSD 4.0. 
3 4jOpenBSD 2.7,2.6; NetBSD 1.4.1,1 .4.2; B5DI BSD/OS 4.0,3.1; Solaris 2.6,2.7,2.8; HP-UX 
m ,'m 1 ;° : Com P a jn;m645.0; Abe 4.1.3.2; Irlx 6.5.3, 6.5.8; Ultrix 4^-4.5; OpenVMS V7.1-2- 
Novel Netware 5.1 SP1. 5.0, 3.12; Microsoft Windows 98/98SE, Microsoft Windows NT WRKS 
SP6a, Microsoft Windows NT Server SP4, Microsoft Windows 2000 Family 



6.9 DF Bit Echoing 

.K 0n ?,VEf ra .?,T 9 u s y stems - when receiving an ICMP Query message with the DF bit set, would set 
the DF Wt with their replies as well. Sometimes It would be In contrast with their regular behavior 
which would be not setting the DF BR in their replies for a regular query that comes with the DF * 
bit not sot. 



6,9.1 DF Bit Echoing with the ICMP Echo request 

J* 19 l???"^ 1 ? trace below i,,ustrates *n ICMP Echo request sent from a Linux box, uslno SING 42 
to a SUN Solaris 2.7 machine: 

LrootQaodfathar bin]# ./sing -echo -G IP_Address 
SlNGing to IP_Address (IP^Addreas) : 16 data bytes 

IS bytes from IP_AddresB: icrap_seo;=0 D*| ttl*243 TO$=Q tirae-188 -289 ms 
IS bytes from IP^Addregs,: icmp^seq^l DPI ttl=243 TOS-0 time=250,O26 ms 

15 bytes from IP_Address: icmp_seq=2 VVi ttl«243 TOS=0 time-2'4^.238 ms 

16 bytes from IP_Address; iomp_saq-3 DPI ttl=243 TOS-0 time~2 60,036 ms 

IP_Address sing statistics 

4 packets transmitted, 4 packets received, 0% packet loss 
round-trip tnin/avg/max » 188 .2B9/234. 662/260 , 036 ms 
rroot®godfataer bin]# 

The tepdump trace: 

17:16:23.527050 if 4 > x»x.x.x > y.y.y.y: icrop: echo request (DP) (ttl 
25S, id 13170) 

4500 0024 3372 4000 ffOl 20f0 



42 The -G option with SING sets the DF Bit with the ICMP Query wrests. 
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yyyy yVYY 08OO 

a30a 0800 
17:16:23.715250 if 4 <. y-y.y.y > 
243, id 18227) ■ 

4500 0024 4733 
xxxx xxxx 0000 
a30a 0B00 

Most of the operating systems that I have checked this behavior against did the same thing. In 
the reply they produced, the DF bit was set. 

Which operating systems are the exceptional and do not echo back the DF bit? 

Linux operating systems based on Kernel 2.2.x, and Kernel 2.4 with the various test kernels, 

tutrix v4.2 - 4.5, and Novell Netware. 

How can we distinguish between those operating systems? 

Frankly it Is quite simple. Since LINUX and Uttrix are using an IP TTL field value of 255 In their 
ICMP Query replies, and Novell Netware uses 128, it is easy to distinguish between those 
groups. If we want to further distinguish between LINUX based systems and Ultrix based 
systems, we can send an ICMP Information request or an ICMP Address Mask request to the 
questioned machines. The machine, which would answer those, will be the one based on the 
Ultrix operating system. 

6.9.2 DF Bit Echoing with the ICMP Address Mask request 

With ICMP Address Mask requests we have a different story. Among the operating systems that I 
have checked that answer for an ICMP Address Mask request Sun Solaris & OpenVMS echo 
back the DF bit Microsoft Windows 98, Microsoft Windows 98 SE r and Ultrix do not echo back 
theDFblt 

Again it Is very simple to distinguish between the Microsoft Windows.98 family and between the 
Ultrix machines. Since the Microsoft Windows 9B family Is using 128 as their IP TTL field value In 
their ICMP query replies and Ultrix uses 255, we can distinguish between those operating 
systems. 

We have here a simple method to distinguish between Microsoft Windows 98 / 98 SE, and Ultrix 
TTiachines to the rest of the operating systems world. 

Another Interesting piece of Information is that the Microsoft Windows 98 family changed its 
behavior from DF echoing with the ICMP Echo request to not echoing with the ICMP Address 
Mask request This inconsistency is a factor with all Microsoft operating systems (Echoing with 
ICMP Echo request, not echoing with the other types of ICMP query). 



a5cd b3 04 0000 37e9 bc39 

x.x.x.x: icmpx echo reply (DP) (ttl 

4000 £301 I92f yyyy yyyy. 
adcd b304 0000 37e9 bC39 



6.9.3 DF Bit Echoing with the ICMP Tlmestamp request 

Since a lot more operating systems answer for an ICMP Tlmestamp request than with the ICMP 
Address Mask request we have a bit more difficulty in identifying those. 

Linux machines based on Kernel 2.2.x, or Kernel 2,4, Ultrix, Microsoft Windows 98/98SE/ME, and 
the Microsoft Windows 2000 Family would not echo back the DF bit with ICMP Tlmestamp replies 
they produce for ICMP Timestamp request that sets their DF bit. 

Here we can only distinguish between certain groups of operating systems; again It would be 
according to their IP TTL field value with their replies. 
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Linux would use 255 as its TTL field value for the ICMP Tlmestamp reply; Utorix would use the 
same value. The Microsoft family of operating systems that would answer for this kind of query 
would use 128 as their TTL value. 

Again we have Linux and Ultrix on the one hand and the Microsoft Family on the other hand. How 
can we further distinguish between those? We can correlate the Information {as discussed in the 
next section, or query the "suspicious" machines with another type of ICMP Query message). 

6.9.4 Using all of the Information In order to Identify maximum of operating systems 
We can group Linux and Ultrix with the ICMP Echo requests. We can do the same with Microsoft 
Windows 98 / 98 SE & Ultrix using the ICMP Address Mask requests. This would allow us to 
pinpoint the Linux boxes from the first Stage. So when we would go Into the third stage we would 
know which operating systems are Linux based, which are Microsoft Windows 98 / 98 SE based, 
and which are Ultrix based. This would leave us with Microsoft Windows ME and with the 
Microsoft Windows 2000 family machines. 



6,9.5 Why this would work (for the skeptical) 

All those skeptical would say that if they receive an ICMP Query request with the DF bit set than it 
should be clear that something is wrong and someone is probably trying to scan them. Think 
again; What would happen if a Sun Solaris machine will query your machine? Than the same 
behavior would be produced. 

This is an ICMP Echo request Sent from a Solaris 2.6 box to a Linux box. We can see that the DF 
bit Is set with the request and not set with the reply. But again if some one would mimic this 
behavior with a tool used on a Linux box to query the world, which Is 100% mimicking a Sun 
Solaris request than we would never know if this is a legit request or an attempt for scanning / 
fingerprinting. 



Initializing Network Interface 

Decoding raw data On interface pppO 

-*> Snort 1 <*- 
Version 1.6 

By Martin Roeach (roesch@clark.net, www.clark.net/-roesch) 
OB/l0-23;32:52. 201612 y«y:y.y -> 139,92.207.58 
ICMP TTL:239 TOS:0x0 ID:4BS56' DP 
ID; 2080 Seq:0' ECHO 

39 93 10 A3 00 03 FO E5 08 09 OA OB OC 0D 0E OP 9, 

10 11 12 13 14 15 16 17 IB 19 1A IB 1C ID IE IF 

20 21 22 23 24 25 26 27 2B 29 2A 2B 2C 2D 2E 2F I {) *+, - . / 
30 31 32 33 34 35 3S 37 01234567 



08/10-23:32:52.201649 139.92.207.58 y.y.y.y 
ICMP TTL;255 TOStOXO ID:349 
ID:2080 Seq;:0 ECHO REPXiY 



39 


93 


10 


A3 


00 


03 


FO 


E5 


08 


09 


OA 


0B 


OC 


OD 


OE 


OP 




10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


1A 


IB 


1C 


ID 


IE 


IF 




20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


2A 


2B 


2C 


2D 


28 


2P 


1 »#$%&■ ()*+, 


30 


31 


32 


33 


34 


35 


36 


37 


















01234567 
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Operating System 


Info. Request • 


. Time Stamp, 
ftequesl >; • 


Address Mask 
' " Request *. 


EchoRegues^* 


Debidn GNU/ LINUX Kernel 
2.4 test 2 

Redhat UNUX 6.2 Kernel 2.2.14 


Not Answering 
Not Answering 


+(-DF) 
+ (*DF ) 


Not Answering 
Not Answering 


+ (-DF) 
+ (-DF) 


FreeBSD4.Q 
FreeBSD 3.4 
OpenBSD 2.7 
OpenBSD 2.6 
NotBSD 

ESDI BSD/OS 4.0 
ESDI BSD/OS 3.1 


Not Answering 
Not An & wo ring 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ (+DF) 
+ (+DF)' 
* (+ DP) 
+ t>DF) 
+ (+DF) 
+ { + DF) 
+ (+DF) 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering . 
Not Answering 
Not Answering 


+ < + DF) 
+ ( + DF) 
+ ( + DF ) 
+ ( + DF) 
♦< + DF) 
+(+DF) 
+ ( + DF) 


Solaris. 315.1 
Solaris 2.6 
Solaris 2.7 
Solaris 2 B 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ { + DF ) 
+ r>DF) 
+ ( + DF) 


+ {+DF) 
+ (+DF) 
+ (*DF) 


+ ( + DF) 
+ < + DF) 
♦(♦DF) 


HFMJXv10_20 
HP-UX v11.0 


Not Answering 


Not Answeifng 


Not Answering 
+ ( + DF) 


+ ( + DF) 


Compaq Tru64 v5.0 




♦ ( + DF) 


Not Answering - 


+ \ + vt- J 


Irix 6.5.3 
Irix 6.5.8 


Not Answering 
Not Answering 


+ t + OF) 
+ <^DF) 


Not Answering 
Not Answering 


+(+DF) 
+ ( + DF ) 


AIX4.1 
AIX3.2 




+ ( + DF) 
+ ( + DF ) 


Not Answering 
Not Answering 


*f>DF) 
+ ( + DF ) 


ULTRIX4^-4.5 




■M-pF) 


+ (-OF) 


+ (-DF) 


OpenVMb Vf .1^2 




+ ( + DF ) 




+ ( + DF ) 


Novell Netware 5.1 SP1 
Novell Netware 5.0 
Novell Netware 3.12 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
■ Not Answering 
Not Answering 


+(-DF) 
+ (-DF) . 
+(-DF) 


Windows 95 
Windows sa 
Windows 38 SE 
Windows ME 

Windows NT 4 WRKSSP 3 
Windows NT 4 WRKS SPfla 
Windows NT 4 Server SP4 
Windows 2000 Professional 
Windows 2000 Server 


NotAnswortng 
Not Answering 
Not Answering 
Not Answering . 
Not Answering 
Nat Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 
+ C-DF) 
•M-DF) 
+ ( -DF) 

Not Answering 
Not Answering 
Not Answering 
+ (-DF> 
-M-DF) 


+(-PF> 
+(-DF) 
Not Answering 

Not Answering 
Not Answering 
Not Answering 
! Not Answering 


4 ( + OF ) 
+ (*DF) 
+ ( + 0F) 

+(+DF) 
+ { + DF> 
+ ( + DF) 



TaWe13:DF Bit Echoing 



6,9, S Combining all together 

If we comWne everything together than we can start from sending ICMP Echo requests with the 
DF bit set probing the targeted host(s) / network(s). The operating systems, which will not echo 
the DF bit with their ICMP Query replies, will be Linux operating system machines based either 
on kernel 2.2.x, or on Kernel 2.4.x, Novell Netware, and Ulttlx machines. We can distinguish 
between the Novell Netware machines, the Linux based machines, and the Ultrix based 
machines according to the IP TTL field values with the ICMP Echo replies. . 
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DF Bit Echoing with the ICMP Echo request 

0 



ECHO 
DFBIt 



Not ECHO 
.the DF Bit 



Other OS's 



Unux Kernel 
Linux Kernel 2.4 

Uitrix v4.2- 4.51^ 

Novell Netware 



TT1, Filed 



DFBIt Echoing With the ICMP Address Mask request 



ECHO 
DF Bit 



Not ECHO 
the DF Bit 



Sun Solaris 



Microsoft Windows 98 
Microsoft Windows 9B SE 



TTLFIred 



DF EHt Echoing with the ICM P Tim estamp request 

ECHO / \ Not ECHO 

DFBIt / \ tho DFBIt 



Unux with Kernel 22* 

OtberOS* Unuxwim Kernel 2.4 

Microsoft Windows 9&/$6$E 
Microsoft Windows ME 
Microsoft Windows 2000 Family 

Diagram 9: An example of fingerprinting using the OF Bit Echoing technique 



The second stage would bo sending ICMP Address Mask requests with the DF bit set to the 
same-targeted host(s), Microsoft Windows 98/98 SE and Uitrix based machines would not echo 
the DF bit with their ICMP Query reply. We than can distinguish between the Uitrix machines and 
the Microsoft Windows machines, because of the different IP TTL field values In the ICMP 
Address Mask replies. 

We can now also Identify the Uitrix machines from the first step - wa know their IPs now. Than it 
leaves us with only the Unux boxes. Within two steps we are able of fingerprinting Novell 
Netware, Uitrix, Microsoft Windows 98/98 SE and Unux operating systems based on kernel 2.2.x 
or on kernel 2.4 jc 
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In the last step of this example we are sending ICMP Timestamp requests with the DF bit set to 
the same group of IPs we are probing. The operating systems which do not echo back the DF bit 
In their ICMP Query replies are Linux operating systems based on Kernel 2.2.x, or on Kernel 2.4, 
Ultrix, Microsoft Windows 9&79BSE, Microsoft Windows ME, and Microsoft Windows 2000 Family. 
Since we already fingerprinted most of the operating systems In this It enable us to fingerprint 
Microsoft Windows ME r and Microsoft Windows 2000 family based machines. 



6.10 Using Code field values different than zero within ICMP ECHO requests 
An interesting detail I have discovered during the lab experiments I did when I have researched 
ICMP scanning Is when a wrong code is sent along with the correct type of ICMP query message, 
different operating systems would send different code values back. 

In the next example I have sent an ICMP Echo Request with the code field value set to 3B instead 
of 0. to a UNUX machine running Redhat LINUX 6.2 Kernel 2.2.14. 

We can look at the tcpdump trace, the type and code fields are In bold type: 



00:21:05.238649 PPPO > x.x.x.x > y.y.y^y: icmp: echo request (ttl 255, 
id 13170) 

4500 0024 3372 0000 ffOl 08d3 xxxx xxxx 

yyyy yyyy 0026 afi3 2904 0000 4ie4 c339 

17a4 0300 

00:21:05.485617 pppO ■< y.y*y*y > x.x.x.x: icmp: echo reply {ttl 240, id 
2322) 

4500 0034 0912 0000 fooi 4233 yyyy yyyy 

xxxx xxxx 0026 b713 2904 0000 41e4 c339 
17a4 0300 



In the ICMP Echo reply LINUX produced the code field value Is set to 38. 

If we examine what RFC 792 requires, we see that LINUX does exactly that. 

The sending side initializes the Identifier (used to Identify ECHO requests aimed at different 
destination hosts) and sequence number (if multiple ECHO requests are sent to the same 
destination host), adds soma data (arbitrary) to the data field and sends the ICMP ECHO 
Request to the destination host. In the ICMP header the code equals zero. The recipient should 
only change the type to ECHO Reply and return the datagram to the sender. 



0 4 8 1B 31 



Type 


Cato"D 


cneeKsun 


tariftr 


SBcparEBNLiTtxr 





Figure 12: ICMP ECHO Request & Reply message format 
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This also means that we trust another machine to behave correctly, when that host produce the 
ICMP Echo reply. ' 

UNIUX changes the type field vaJue to 0 and sends the reply. The code field Is unchanged. 

I have checked the behavior of my Microsoft Windows 2000 Professional box. I have sent the 
same ICMP ECHO Request message to the Microsoft Windows box (the code field Is In bold 
type): 



10:03:33 .860212 ethO > localhoat. locaXdoroain > 132. 168.1*1: icmp : echo 

4500 0020 3372 00O0 f*01 06.14 C0a3 0105 
C0a8 0101 0826 d618 6102 f 653 0193 cfie2 



10:03:33.860689 ethO < 192.168.1.x 
reply 

4500 0020 2010 0000 B001 9776 cOaB 
C0a8 0105 0000 de3e 6102 £658 0183 
0000 0000 0000 0000 0000 0000 0000 



localhost . local'domain : icmp z ■< echo 



0101 
c8e2 



The Microsoft Windows 2000 Professional operating system changed the code field value on the 
ICMP Echo Reply to the value of 0. 

This method was tested with various operating systems including LINUX Kernel 2,4t1-8 F IBM AIX 
4.x & 3.2, SUN Solaris 2.51, 2.6, 2 J & 2.8. OpenBSD 2.6 & 2.7, NotBSD 1.4.1, 1.4.2, BSDI 
BSD/OS 4.0 & 3.1, HP-UX 10.20 & 11 .0, Compaq Tru64 v5.0, Irix 6.5.3 & 6.5.8, Ultrlx 4.2-4.5, 
OpenVMS, FreeBSD 3.4, 4.0 & 4.1 and they produced the same results as the LINUX box 
(Kernel 2.2.x) did. 

Microsoft Windows 4.0 Server SP4, Microsoft Windows NT 4.0 Workstation SP 6a, Microsoft 
Windows NT 4.0 Workstation SP3, Microsoft Windows 95 / 98 / 98 SE / ME have produced the 
same behavior as the Microsoft Windows 2000 Professional (Server & Advanced Server). 

We have a fingerprinting method to differentiate between a Microsoft Windows based machine to 
the rest of the operating systems world using code values, which are different than zero, inside 
ICMP Echo Requests. 



6.11 Using Coda field values different than zero within ICMP Tlmestamp Request 

I have decided to map which operating systems would answer to an ICMP Tlmestamp Request 
that would have its code field not set to zero, and how the ICMP Tlmestamp reply (if any) will help 
us Identify those operating systems. 



6.11.1 The non-answering Operating Systems 

Interesting results were produced. The Microsoft Windows 98/98 SE/ME, and the Microsoft 
Windows 2000 Family that have answered to ICMP Tlmestamp requests with the code field set to 
zero* now did not produce any reply back. 

This enables us to group together certain versions of the Windows Operating System. 
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The next diagram shows how we can distinguish between the different Microsoft Windows 
operating systems using two datagrams of JCMP Tfmestamp request Th© first one is a regular 
one; the Microsoft Windows machines that do not answer are Microsoft Windows 95 and . 
Microsoft Windows NT 4.0 Workstation with SP 6a. All other operating systems (that I have 
tested) answer the ICMP Time stamp request The second stage is sending another datagram, 
this time with thB Code field set to a value, which Is not equal to zero. The operating systems that 
would not answer will Include Windows 98/98 SE/ME/2000 family, which are the newer versions 
of Microsoft Windows operating systems. 



ICMP Timestamp Request 

0 

Reply / \ No Reply 



Other OS's 



Windows 95 

Windows NT 4 WRKS SP6a 



ICMP Timestamp Request with CODEl^O 

® 

Reply / \ No Reply 



Windows 98 

Other OS's Windows 98 SE 

Windows ME 
Windows 2000 Proffeslonal 
Windows 2000 Server 

Diagram 10: Finger Printing Using ICMP Timestamp Request and Wrong Codes 

It is quite obvious that Microsoft have tried to change some of their newer operating systems 
fingerprinting In later TCP/IP Implementations of their operating systems. For example, the default 
for answering an ICMP Timestamp request was changed from "no answer" to "answer", like UNIX 
and UNIX-like operating systems. But the Microsoft programmers / designers / architects / 
security engineers did not think about every thing apparently. 



6.11.2 Operating Systems the Zero out the Code field value on Reply 

I was looking to see If there are any operating systems In which answered the crafted ICMP 
Timestamp Query with the Code field set to a value different than zero, which might zero out this 
field value in its ICMP Echo Reply, 

I have found that LINUX operating systems based on Kernel 2,2.x or on the 2.4 Kernel (with the 
various test Kernels) zero out the code field with the ICMP Echo replies they produce- The next 
trace is a tcpdump trace describing ICMP Echo Request and reply from a LINUX 2.4 test Kernel 
6, to a crafted ICMP Echo Request with a code field different than zero: 
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[root®godfat&er /root]# Bing -tstatnp -x 38 2 IP_Address 
SINGiug to iP_Address UP_Atfdre33) : 20 data bytes 
20 bytes. from IP_Addreee: icmp_seq=0 ttl«243 TOS-0 diff ^24315927 
20 bytes from IP^Addreaa : icrnp_seq=l. ttl-243 TOS=0 dif f-24316176 

IP_AddreBs sing statistics - — 

2 packets transmit bed, 2 packets received, 0* packet Iobs 
troot^godfather /root] # 



20:10:18. 1384B6 pppO > X.x.x.x > y.y.y.y: icmp? time stamp request (tcl 
.255, id 13170). 

4500 002B 3372 0000 ffOl 605c xxxX XXXX 
yyyy yyyy 0d26 2e0c 7C04 0000 03af 451a 
0000 0000 00Q0 0000 

20:10:1B. 354222 pppO < y.y.y.y > x.x.x.x; icmp: time stamp reply (ttl 

243, id 15717) 

4500 002B 3d6S 0000 f301 S279 yyyy yyyy 
xxxx xxxx OeOO 88Bb 7Cp4 0000 03af 4Sla 
0422 4e31 0422 4e31 

20:10:19.134165 pppO > x.x.x^x > y.y-y.y: icmp: time stamp reque&t (ttl 

355, id 13170) 

4500 002B 3372 0000 ffOl 606c XXXX XXXX 

yyyy yyyy od26 2$28 7c04 0100 o^af 48fe 
0000 0000 0000 0000 

20:10:19,354210 pppO < y.y.y.y > x,x.x-x: icmp: time stamp reply (ttl 
243, id 15718) 

4500 0028 oooo f30i 6278 yyyy yyyy 

xxxx xxxx OeOO 7bed 7c04 0100 03af 4Bfe 
0422 520& 0422 520e 



6.11.3 Changed Patterns 

The LINUX operating system behavior with the crafted ICMP Tlmestamp requests Is In contrast 
with its behavior v\nth the crafted |CMP Echo Requests sent with the Code field set to a value 
different than zero. 

This also gfves us a unique piece of Information that enables us to identity LINUX machines 
better. 
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ICMF> &ho Ftoqueflrt with Oxtel*! 

Reply with 





® 



Other OS*» 

ICMP Time stamp Raquo^t with CODB=0 
Reply vsHth COdo=0 Reply wHth codaMf 



Micro Windows Famfly 



UNUX Kamet 



Other OS's 



|CMF" Time stamp Request 
No Reply 




Windows 95 
Windows HV A WRKS SP6a 



Windows Bfl 
Windows 9B S6 

Windows 2000 Fdmllf 



Diagram 1 1 : An Example of Finger Printing Using crafted ICMP Echo & Timestamp Request 



The diagram above describes a process in which we can use in order to differentiate between 
certain groups of operating systems. 

The first step is sending an ICMP Echo request with the coda field set to a value different than 
zero. The ICMP Echo replies with the code field equal to zero would distinguish the Microsoft 
based operating systems group, from the other UNIX and UNIX-like operating systems. 

Sending ICMP Timestamp requests with the Code field value different than zero to all participants 
of the group of the UNIX and UNIX-like operating systems will identify LINUX 2.2.x and 2.4 Kernel 
based machines (since they zero out the code field in their replies). 

Sending ICMP Timestamp request to the Microsoft Windows based group of operating systems 
will separate the group to those machines rather being windows 95 or windows NT 4 SP4 and 
above (not answer the query), to those that may be one of the following - Microsoft Windows 98 / 
SE / ME / Windows 2000 Family (answer the query). 



For a list of ICMP Query message types sent to different types of operating systems with the 
cod© field set to a value different than zero, and the various ICMP Queryreplles we got back (If 
any) please see -Appendix D; ICMP Query Message types with Code field J=o (table)". 



Using the ICMP Error Messages 

6.12 Operating system, which do not generate ICMP Protocol Unreachable Error 
Messages 

Several operating systems will not generate an ICMP Protocol Unreachable error message, when' 
one Is expected to be produced, in response to an offending datagram trying to use a protocol, 
which is not used on those operating systems* 
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Those operating systems Include: 

• AIX 

• DCMJX 

• HP-UX 



6.13 ICMP Error Message Quenching 

RFC 1812 and RFC 1 122 suggest limiting the rate at which various error messages are sent 
Only few operating systems are known to follow this. 

An attacker can use this to send UDP packets to a random, high UDP port and count the number 
of ICMP Destination unreachable messages received within a given amount of time. 



G.14 ICMP Error Message Quoting Size 

Each ICMP error message includes the Internet Protocol (IP) Header and at least the first 8 data 
bytes of the datagram that triggered the error (the offending datagram); more than a bytes may 
be sent according to RFC 1 122. 

Most of the operating systems will quote the offending packets IP Header and the first 8 data 
bytes of the datagram that triggered the error. Several operating systems and networking devices 
wW parse the RFC guidelines a bit different and will echo more than 8 bytes. 

Which operating systems will quote more? 

UNUX based on Kernel 2.0.x/Z2.x/2.4.t-x, Sun Solaris, HPUX It* MacOS 7.55/8^/9,04. Nokia 
boxes, Foundry Switches (and other OSs and several Networking Devices) are a good example. 

The fact Is not new. Fyodor outlined this In his article "Remote OS Identification by TCP/IP 
Fingenprinting" 43 . 

The idea is in trying to differentiate between the different operating systems that quote more than 
the usual. How can this be done? Looking for example on the amount of Information quoted. Is 
there a limit to the quoted size? Will the quoted data be the entire offending packet or just part of 
it? Will the quoted data be the echoed correctly? Will extra bytes will be padded to the echoed 
data? and some other parameters. 

The next example Is with Sun Solaris 7. 1 have sent a UDP datagram to a dosed UDP port: 

00:13:3S. 559347 pppO > 3C.X-X.X.10B4 > y.y .y .y .2000 : udp 0 (tfcl 64, id 
44551) 

4500 001c ae07 0000 4011 7aa4 xxxx xxxx 
yyyy yyyy 043c 07d0 0008 alac 

00:13:35.923591 pppO < y.y*y»y > x.x.x.x; icmp: y,y-y-y udp port 2000 
unreachable Offending pkt; x.x.x.x.1084 > y.y.y.y.2000 ; udp 0 (fctl 45, 
id 44551) (DF) (ttl 236, id 63417) 

4500 0038 f7b9 4000 ecoi 44e5 yyyy yyyy 

xxxx XXXX 0303 4f3C 000O 0000 4500 OOlc 

ae07 oooo 2dii 8da4 xxxx xxxx yyyy yyyy 
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043c 07d0 0008 alac 

Please note that for having more than 8 data bytes quoted, you need to have data in the 
offending datagram. If not, there is nothing to quote beyond the regular 8 bytes (usually, if the OS 
is not padding other data bytes). 

The next example Is with Sun Solaris B. I have sent a UDP datagram to a dosed UDP port, 
adding 80 bytes of data to the datagram. 

tirootagodf ather] # hpinga -2 80 -a 1 y.y.y*y 

ethO default routing interface selected (according to /proc) 

HPING y-y.y.y (ethO y.y.y.y): udp mode set, 28 headers + 60 data bytes 

icmp Port unreachable from y.y.y.y (y.y-y-y> 

— y.y.y.y bpiE-g statistic 

1 packets tramitted, 0 packets received, 100% packet loss 
round- trip min/avg/max -0.0/0.0/0.0ms 

The tcpdump trace: 

11:52:50.830383 et*0 > x,x.x,x.2198 > y.y.y.y*Q; udp 80 (ttl 64, id 
17240) ■ 

4500 006c 4358 0000 4011- 99ae xxxx xxxx. 
yvyy yyyy 0836 0000 0058 8b5f 5B58 5858 
585$ 5858 5658 5856 5656 5858 5858 5858 
58S8 5858 5858 5856 5858 585B 5858 5858 
5858 5858 5858 5858 5859 5858 5858 5858 
585B 585B 5858 5858 5858 5858 5858 5658 
5858 5858 5858 5858 5858 5858 

11:52:51.367331 etho < y.y.y.y > x.x.x.*: ictnp? y.y.y.y udp port 0 
unreachable Offending pkt; x>x.x,x f 2198 > y.y.y^y.O: udp so (ttl 48, id 
17240) (DP) (ttl 231, id 49576) 

4500 0070 cia8 4000 e701 34 69 yyyy yyyy 
xxxx xxxx 0303 bf05 0000 0000 4500 006c 

4358 0000 3011 a9ae xxxx xxxx yyyy yyyy 

0896 0000 0058 8b5f 5858 5858 5858 5858 

5858 5858 5B58 5858 5858 5858 5858 5858 

5858 5858 5858 5858 5856 5858 5858 5658 

5858 5858 5B5B 5858 5858 5858 5858 5858 

The result Is an ICMP Port Unreachable Error message that will echo only 64 bytes of the 
offending datagram's data portion. 

The Omit of 64 bytes quoted from the offending packet's data portion is not limited to Sun Solaris 
only. HPUX 11.x, MacOS 7.55/6.x/9.04, will do the same. 

Other operating systems / networking deuces will have their own barriers. For example, LINUX 
based on Kernel 2.2jc/2.4.x-t will send and ICMP Error Message up to 576 bytes long, LINUX will 
quote 528 bytes from the data portion of the offending packet (576 minus 20 bytes of usuall IP 
Header, minus 8 bytes of the ICMP Header, minus the offending packets IP Header that Is 20 
bytes will leave you with 528 bytes of data portion. This is no IP options are presented). 

1 know an operating system, and a family of networking devices that will pad extra data to the 
echoed offending packet. LINUX case Is detailed in the next section. The next example Is with 
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Foundry Networks Serveriron running software version 07-1.02T12. 1 have sent a UDP datagram 
. to a closed UDP port on the Foundry switch: 

[rootogodf ataer] # hping2 -2 -c 1 y-y.yly 

ethO default routing interface selected (according to /proc) 

HPING y-y-y + y (ethO y.y.y.y) ; udp mode set, 2a headers + 0 data bytes 

ICMP Port unreachable from y.y*y*y fy-y-y-y) 

y-y-y-y bping statistic 

l packets tramitted, 0 packets received, 100% packet loss 
round-trip min/avg/raax - O.O/O.Q/Q.Q ms 
[root®godf ather] # 

12:08:47.793503 ethO > X.X.X.X.249B > y.y«y.y-0: Udp 0 (ttl 64 , id 
44437) 

4500 001c ad&5 0000 4011 885f xraoe xxxx 

yyyy yyyy 05c2 0000 0008 bi3f 

12:08:49.240208 ethO < y-Y-Y-Y > x.x.x.x: icmp: y.y*y.y udp -port 0 
unreachable Offending pkt: x.x.x.x.2498 > y-y-y-y-0: udp 0 (ttl 51, id 
44437) (ttl 51, id 17453) 

4500 0044 445d oooo 3301 feaf yyyy yyyy 

xxxx xxxx 0303 739c 0000 0000 4500 001c 
a<J95 0000 3311 955f xxxx xxxx yyyy yyyy 
09C2 0000 0000 bi3£ dd2c 2alS 3Bel 764G 
7aaa 9d41 

As it seems Foundry switches will pad 12 bytes with ICMP Port unreachable. 



Other fingerptintlng facts that are outlined through this section will halp us to differentiate between 
the operating systems, which carry the. same behavior. 

V 

I have examined three ICMP Error Messages a Host can issue: 

• ICMP Port Unreachable 

• ICMP Protocol Unreachable 

• ICMP IP Reassembly Time Exceeded 

Other ICMP Error Messages, which a Host can issue and should be checked to sea if they hold 
more fingerprinting differences, are: 

• Source Quench 

• Parameter Problem 



6.15 LINUX ICMP Error Message Quoting Siae Differences / The 20 Bytes from No 
Where 

We must understand that there are differences between the different ICMP Error messages, not 
only with their meaning, but also with their Implementation. I was expecting that several 
characters with the ICMP Error messages will be the same along all of the ICMP Error Messages, 
but I was wrong regarding few operating systems. 
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The most interesting case is with the LINUX operating system based on Kernel 23.x and 2.4.t-x* 

The next example Is with LINUX based on Kernel 2.2.1 6 as the targeted machine, eliciting an ■ 
ICMP Port Unreachable error message: 

00:21:30.199406 pppO > X.X.X.X.2066 > y .y :y .y .2000 : Udp 0 {ttl 64, id 
1732) 

4500 001c 06C4 0000 4011 CS95 xxXX xxxx 

yyyy yyyy osi2 07do 000a 4464 

\ 00:21:30.493691 pppO < y.y.y*y > x.x,X.X: icrap: y.y-y-V udp port 2000 
unreachable Offending pkt: x.x.x*x.20fiG > y.y.y.y.2000: udp 0 (ttl 44, 
id 1732) [tOS 0xc03 (ttl 238, id 53B04) 

4Sc0 0038 d22c 0000 eeOl 4eG0 yyyy yyyy 
xxxx xxxx 0303 aBBe 0000 0000 4500 001c 
06c4 0000 2cll dc95 xxxx xxxx yyyy yyyy 
0812 07d0 0008. 4484 



The quoted data is the entire offending datagram. LINUX ICMP Error messages will be up to 576 
bytes long according to the LINUX source code. 

The next example is with LINUX as the targeted operating system- With this example I have sent 
a protocol scan with NMAP: 

13:14:56.942897 < x,X.X.X > y.y-Y-y: ip-proto-3$ 0 (ttl 39, id 37623) 
4500 0014 92£7 0000 2726 02cb XXXX XXXX 

yyyy yyyy _ ■ 

13:14 = SS. 942964 > y.y.y.y > x.x.x.x: icmp; y-y-y-y protocol 3,8 
unreachable offending pkt: x.x.x.x =» y.y.y.y: ip-proto-38 0 (ttl 39 f id 
37623) [tOS OxcO] (ttl 255, id 1884) 

4Sco 0044 075c oooo ffoi b59a yyyy yyyy 

xxxx xxxx 0302 fbla 0000 0000 4S0O 0014 

92f 7 oooo 2726 02cb xxxx xxxx yyyy yyyy 

0050 dc84 ae6f 6910 0000 0000 5004 0000 
bd89 0000 

LINUX adds to the entire offending packet that was quoted, another 20 bytes. 

Since LINUX, handles the ICMP Protocol Unreachable Error Messages like the ICMP Fragment 
Reassembly Time Exceeded Error Messages we will see the same pattern with ICMP Fragment 
Reassemb^Tlme Exceeded: 

[rootogodfather binl# hping2 -c 1 -x -y y.y.y.y 
pppO default routing interface selected (according to /proc) 
HP TNG y.y.y.y pppO y.y.y.y): NO FIAGS are set, 40 headera + 0 data 
bytee 

y.y.y.y hping statistic 

1 packets tramitted, 0 packets received, 100% packet loss 
round- trip min/avg/Tnax » o.b/o. 0/0.0 ins 
[rootegodfatner bin]# 

The tepdump trace: 
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19:49:22.999X08 pppO > X.x.x. x. cvapserver > y-Y*Y-Y.O: • 
17 09055398 = 170'9055398(0) win 512 (frag 35247;20®O+) (DP) (ttl 64) 
4500 002B 89af 6000 4006 eOff xxxx xxxx 

yyyy yyyy- 0961 00 °o 65de 1<ia6 6a0X * 76b 
5000 0200 bf7i oooo 

19:49:53,3033-96 pppO. < y.y.y.y > x.x-x.X: icmp: ip reassembly time 
exceeded Offending pktj x.x.x*x*cvBpeerver > y.y«y.y*0= - 
1709055398:1709055398(0) win 512 (frag 35247:20®0+) (DF) (ttl 45) [toe 
OxCD] (ttl 238, id 379) 

45co 0058 oi7b oooo eeoi 1^49 yyyy yyyy 

xxxx xxxx ObOl 3caf 0000 0000 4500 002B 

esaf 6ooo 2dD6 f3ff xxxx xxxx yyyy yyyy 

0961 0000 65de lda6 €a01 476b 5000 0200 
bf7l 0000 601d IrOd 7a04 5045 0100 0000 
4146 4345 4a45 4f46 

Since LINUX's ICMP Error messages will not be bigger than 576 bytes long. If the offending 
packet win be Wg enough (not likely in real world situation) we will not see the added 20 bytes in 
the ICMP Fragment Reassembly / ICMP Protocol Unreachable error messages. 

This unique pattern will allow us to identify LINUX based machines even rf the Precedence Bits 
value with the LINUX ICMP Error messages will be changed to 0x000. 
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6.16 Foundry Networks Networking Devices Padded Bytes with ICMP Port 
Unreachable(s) / The 12 Bytes from No Where 

Linux is not the only operating system that will have weird data bytes padded to one of his ICMP 
Error messages. 

Foundry Network's networking devices will pad extra 12 bytes of data with their ICMP Port 
Unreachable Error messages. Our first example is with a Served ran switch running software 
version 7.1.02T12, eliciting an ICMP Port Unreachable error message: 

IrootGgodfather] # hping2 -2 -c 1 y.y.y.y 

ethO default routing interface selected {according to /proc) 

hping y.yiy.y (ethO y.y.y.y) ; udp tnode set, 28 headers + o data by tee 

icmp Port Unreachable from y.y.y.y (y-y-y-Y) 

— - y.y.y-y hping statistic 

1 packets tramitted, 0 packets received, 100% packet lofiS 
round- trip min/avg/max = 0.0/0.0/0.0 ras 
[rootagodf ather] # 

12s08:47,793503 ethO > x.x.x.X.2498 > Y-Y-Y-Y' 01 Udp 0 (ttl 64, id 
44437) ' 

4500 001c ad95 0000 4011 8B5f xxxx xxxx 

yyyy yyyy osc2 oooo oooa bi3f 

12:0B?48. 240208 etho < y.y.y.y > x.x.x.x: icrap = y.y.y.y udp port o 
unreachable Offending pfct: x.x.x.x.2498 > y.y.y.y. 0: udp o (ttl 51, id 
44437) (ttl 51, id 17453) 

4500 0044 442d oooo 3301 feaf yyyy yyyy 

xxxx XXXX 0303 739C 0000 0000 4500 001c 
94 
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ad95 oooo 3311 955f xxxx xxxx yyyy yyyy 
09c2 OOOO 0008 bl3f dd2o 2*}.6 38el 7646 
7naa 9d4l 

From the tcpdump trace we can see that the offending packers IP header and the first 8 data 
bytes were echoed correctly. Right after those, 12 bytes were padded, that came from nowhere. 

The next example Is with Foundry Network's BIglron 8000 running software version 6.6.05T51, 
With this test I have sent a UDP datagram with HO bytes of data to a dosed UDP port on the 
BIglron B000: 

[rootflgodfather /root] # hping2 -2 -c 3 -d 80 y.y-y:y 
pppO default routing interface selected (according to /proc) 
OTXHG y.y*y.y <pppO y-y.y-y > = udp mode set, 28 headers + BO data 
bytes 

ICMP Port Unreachable from y.y.y»y . (y-y.y^y) 
iCWP Port unreachable from y,y-y.y (y«y-y-y) 
ICMP Fort Unreachable from y.y.y.y (y.y-y.y) 

— y.y.y.y hping statistic 

3 packets tramitted, 0 packets received, 100% packet lose 
round- trip rain/avg/raax c 0 . 0/0 .0/0.0 ma 
[rootogodfather /root J # 

11:40:36.694235 pppO > X,X,;>c.x. 2779 > y,y-y-y-0: udp BO (ttl 64, id 
25211) 

4500 006c 627b 0000 4011 2e7a TOasx xxksc 

yyyy yyyy Oadb oooo ooss 3d09 5858 5858 

5858 5858 5858 5858 5058 5858 5858 5858 

585B 5B58 5858 5858 5958 5858 58SS 5858 

5858 5858 5858 5858 5858 5858 5858 5858 

5B58 5858 5858 5858 5858 5858 5858 5858 
5858 5858 5858 5858 5858 5858 

11:40:37,313018 pppO < y.y.y.y > x.x.x.x: icrap: y*y.y-y udp port o 
unreachable Offending pkt: dc*x.x:x.2779 > y.y-y-y-Q: u<%> 80 (ttl 52, id 
25211) {ttl 52, id €0504) 

4500 0044 ecsa 0000-3401 bbd4 yyyy yyyy 
xxxx xxxx 0303 edf 3 0000 0000 4500 OOtfa 
627b 0000 3411 3a7a xxxx. apacx yyyy yyyy 
Oadb 0000 0058 3d09 iCld lelf 2021 2*23 
2425 2627 

Again, the offending packets IP Header and the first 8 data bytes are quoted correctly. 12 data 
bytes are padded right after. 

A nice pattern that allows us to identify Foundry Network's networking devices. 




6.17 ICMP Error Message Echoing Integrity (Tested with ICMP Port Unreachable) 

When sending back an ICMP error message, some stack Implementations may alter the original 
IP header, which is echoed back with the ICMP error message. 
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If an attacker examines the types of alternation that have been made to the headers, he may be 
able to make certain assumptions about the target operating system* 

The only two field values we expect to be changed are the IP time-to-live field value and the IP 
header checksum. The TTL field value changes because the field Is decremented by one, each 
time the IP Header is processed. The IP header checksum Is recalculated eanh lime the IP TTL 
field value decremented. 



Fyodor gives the following examples in his article "Remote OS detection via TCP/IP Stack Finger 
Printing" 44 : 

"For example. A1X and BSDI send back an IP 'total length' field that Is 20 bytes too high. 
Some BSDI, FreeBSD, OpenBSD, ULTR1X, and VAXen change the IP ID that you sent . 
them. While the checksum Is going to change due to the changed TTL anyway, there are 
some machines (AIX, FreeBSD, etc.) which send back an inconsistent or 0 checksum. 
Same thing goes with the UDP checksum* 



This section deals with the ICMP Port Unreachable error message. 



AIX 4.2.1 , 4.3, 4.3 fix pack 2 

In the next example I have sent a UDP datagram to a closed UDP port on an AIX 4.3 machine 
using HPING2. This Is the tcpdump trace: 

12r33 = 17. 319275 pppO > x.x* x.x. 2160 > Y~Y>Y-Y-°- udp 0 [tos 0x10] (ttl 
64, id 47349} 

4510 001c b8fS 0000 4011 9bea xxxx xxxx 
yyyy yyyy 0870 0OO0 0008 dl8C 

12:33:17. 614823 pppO < Y-Y-Y-Y > x.x.x.x: icmp: Y~Y*Y*Y uti p port 0 
unreachable Offending pkt: x.x*x,x.2l60 > y.y.y.y.O: udp o [toa 0x10] 
(ttl 49 , id 47349, bad cksum aaeai) [toe 0x10] (ttl 241, id 17965) 
4510 0038 462d 0000 flOl 5da6 yyyy yyyy 
xxxx xxxx 0303 f470 0000 0000 4510 0030 
bfifS 0000 3111 aa§ft xxxx xxxx yyyy yyyy 
0B70 0000 0008 0000 

We can Identify several changed between the original IP Headers to the echoed ICMP Header 
with the ICMP port unreachable error message. 



• IP Total Length Field - The total length field with the original UPP datagram equal to 
28 bytes. With the echoed original IP header this value was changed to 43 bytes. 20 
bytes more than the original UDP datagram's length. 

• IP TTL Field value - With the ICMP error message this value Is set to the value, 
which reached its final destination (with this example the targeted host). When it 
reached It target the TTL was set to 49. We also learn the target Is 64-49 = 15 hops 
away- ' 

• IP Header Checksum - The IP Header checksum was changed because the IP Total 
Length filed value and the IP TTL field value were changed. 
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• UDP Header Checksum - The UDP header checksum wfth the echoed Information 
equal to zero. 



In the next example I have sent a UDP datagram to a closed UDP port on an A1X4.1 machine 
using HPING2. This is the tcpdump trace: 



00x56:07. pppO > x.x.x.x.1594 > y.y.y.y-O: Udp 0 Itps 0x8] (ttl 
64, id 2153) 

450B 001c 0869 0000 40ll c54£ XxXX XXXX 

yyyy yyyy o63a oooo ooos 4c93 

00:56:08.204551 pppO < y.y.y-y > x.x*x,x: iomp: y.y-y.y udp port a 
unreachable Offending pkt: x,x.x.x.i594 > y.y.y-y-°: udp 0 [tos 0x81 
(ttl 47, id 2153, bad cfcsum d$4f 1) [tos 0x8] (ttl 239, id 1065) 
4508 003B 0429 0000 ef 01 ia$3 yyyy yyyy 
xxxx xxxx 0303 aal3 0000 0000 4508 0030 
0869 oooo 2fii d64f xxxx xxxx yyyy yyyy 

063a 0000 000a 4C93 

Wfc can Identify several changed between the original IP Headers to the echoed ICMP Header 
with the ICMP port unreachable error message, 

• IP Total Length Field - The total length field with the original UDP datagram equal to. 
28 bytes. With the echoed original IP header this value was changed to 48 bytes, 20 
bytes more than the original UDP datagram's length. 

• IP TTL Field value - With the ICMP error message this value Is set to the value, 
which reached Its final destination (with this example the targeted host). When It 
reached it target the TTL was set to 47, We also learn the target Is 64-47 - 1 7 hops 
away. 

• IP Header Checksum - The IP Header checksum was changed because the IP Total 
Length filed value end the IP TTL field value were changed. 



ICMP Error Message echoing Integrity with different 4*x versions of ADC 

In contrast to AlX version 4.3 and 4.2.1 AIX version 4.1 use the original UDP Checksum. This 

detail helps us to differentiate between the different versions of ADC 



BSDI 4jc 

In the next example I have sent, again, a UDP datagram to a close UDP port, this time on a BSDI 
4.1 machine. The following is the tcpdump trace: 

QliOlill.128420 pppO > x.x.x.x.2933 > y.y.y.y-O: udp 0 [tos 0x8] (ttl 
64, id 49317) 

4503 001c COaS 0000 4011 920& XXXX xxxx 
yyyy yyyy 0b75 0000 0009 CC4e 

01:01:11.484552 pppO <: y.y.y.y.4 > x.X.X.X: icmp: y.y.y.y udp port 0 
unreachable Offending pxts x,x.x.x.2933 > y.y.y-y.O: udp □ [tos 0x8] 
{ttl 53. id 49317, bad ckpum 01) (ttl 242, id 16127) 

4500 0038 3eff 0000 £201 6iab yyyy yyyy 
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xxxx xxxx 0303 C226 OOOO 0000 4S09 0030 

coa5 oooo 35ii oooo xxxx xxxx yyyy yyyy 

Qb75 0000 0008 cc4e 



Again several changed were made to the original IP Header. 

• IP Total length - With the echoed IP Header this field value was changed from the 
original 28 bytes to 48 bytes. 20 bytes more than the original. 

• IP TTL Held Value - Changed according to the hop count Was equal to 53 when 
arrived to Its destination. The target Is 64 - 53 * 1 1 hops away. 

• IP Header Checksum - changed now it equal to zero! 



FreeBSD 3.x up to 4.1.1 (not including) 
The next example is with FreeBSD 4.1:* 

00:52:19-055758 pppO > x.x.X-x. 1393 > y.y.y-y-0* Udp 0 [tos 0x8] (ttl 
S4, id 58365) 

4506 001C eS55 0000 4011 3f63 xxxx xxxx 

yyyy yyyy 0571 oooo ooos asse 

00:52:19. 46454B pppO < y*y.y.y > x.x.x.x: icmps y-y.y-y udp port o 
unreachable Offending pkti x.x.x.x*1393 > y.y.y.y.0; udp 0 [tos 0x6) 
(ttl 47, id 21SS0, bad ckeum 5063!) (ttl 238* id 27639) 

450p 0038 Sbf7 0000 eeOl Obbd yyyy yyyy 
XXXX XXXX 0303 B7f3 0000 0000 450B 001C 

SSeS 0000 2£li 5063 xxxx xxxx yyyy yyyy 
0571 0000 0008 OOOO 



• The IP Identification field value is changed. This field is constructed with 16bit. The 
first B bits changed places with the second pair of a bits constructing this field. Wrth 
the original datagram this field value was e655, with the echoed IP header it Is 

• the IP TTL field value has. changed* The target is 64 - 47 = 17 hops away, 

• the IP Header Checksum have changed because of the parameters wore changed 
as well, 

• The UDP checksum Is changed and now it equal to zerol 



Operating 

■SystenY. " 

\ .\ ' ' t ' | * 


DF Bit set 
with trie : • 
Reply?. 


IP Total: 
Length 


jP.\ • 
tdentificatlo 
n . 


iPTTU 
field value 


IP Header ... . 
Checksum 


\ UDP 
Checksum 


LINUX Kernel 


No 


Same 


Same 


"Changed 


Changed 


Same 


2.2.X 








according 


because of new 












to hop 


parameters. 












count 






LINUX Kernel 


No 


Same 


Same 


Changed 


Changed 


Same 


2A 








according 


because of new 












to hop 


parameters. 












count 







* 6 http://www freBb3d! Q r^^ : Patches were Issued. This la fixed with FreeBSD 4.1-1. 
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FreeBSD 4.0 


No 


Same 


Changed. 
The first 
two bits 
are flipped 
with the 
second 
pair. Gives 
anew 


Changed 
according 
to hop 
count. ! 


Changed 
because of new 
parameters. 


Changed. 
Now equal to 
ZERO! 


FreeBSD4.11 
BSDI 4.1 


No i 
No 


Sam© 

Changed 
(20 bytes 
more) 


value. 
Same 

Same 


Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 


Changed 
because of new 
parameters. 

Changed. Now 
equate to ZERO! 


Changed. 
Now equal to 
ZERO! • 

Same 


Sun Solaris 
2.6 

Sun Solans 
2.7 

Sun Solaris 
2.S 46 


Yes 
Yes 
Yes 


Same 

Same 
Same . 


Sama 
Same 
Same 


Changed 

according 

to hop 

count. 

Changed 

according 

to hop 

count. 

Changed 

according 

to hop 

count 


Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 


Same 
Same 
Same 


HPUX11.0 

Compaq 
Trub*4 

DG-UX5.6 


No -> Yes 

No 

No 


Same 
Same 
Same 


Same 
Same 
Same 


Changed 

according 

to hop 

count. 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 


Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 


Same 

Changed. 
Now equal *0 
ZERO! 

Changed. 
Now equal to 

ZERO! 


AIX4.3 fp2» 
4,3,4.2.1 

AIX4.1 


No 
No 


Changed 
(20 bytes 
more) 

Changed 
(20 bytes 
more) 


Same 
Same 


Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 


Changed 
because of new 
parameters, 

Changed 
because of new 
parameters. 


Changed. 
Now equal to 
ZERO! 

Same 



a The DF Bit Is set ^ 
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Operating 
".System 



ULTRJX 



OpenVMS 



Microsoft 
windows 98 

Mirosoft 

Windows 

98SE 

Microsoft 
Windows ME 



Microsoft 
Windows NT 
4 

Microsoft 
Windows 
2000 Family 



DF Bit set"" 
with the 1 • 
Reply?' 



No 



No 



No 



No 



No 



No 



IPTotal 
Length 



Same 



Same 



Same 



Same 



Same 



Same 



IP . . ' 
identJftcatto 



Changed. 
The first 
two bits, 
are flipped 
with the 
second 
pair. Gives 
anew 
value, 

Changed. 
The first 
two bits 
are flipped 
with the 
second 
pair. Gives 
anew 
value. 



Same 



Same 



Same 



Same 



IP.TTL 
fjeld value 



Changed, 
according 
to hop 
count 



Changed 
according 
to hop 
count 



Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 



: IP Header 
. ChecKsum 



Changed, Now 
equate to ZEftOJ 



Changed. Now 
equals to ZERO! 



Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 



UDP ^ 
Checksum 



Changed. 
Now equal to 
ZERO! 



Changed. . 
Now equal to 
ZERO! 



Same 



Same 



Same 



Same 



Table 14: ICMP Error Message Echoing Integrity 



6.18 Novell Netware Echoing Integrity Bug with ICMP Fragment Reassembly Time 
El x c o pded 

Novell Netware operating systems have a unique pattern with ICMP Fragment Reassembly Time 
Exceeded error messages they produce, 

c 

In general, when an ICMP error message Is produced, the offending packet's IP Header + at least 
fl bytes of data are echoed with the error message. 

It* we examine closely the next example, we can see that the Offending packets IP TTL field 
value echoed back Is zero. 
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We expect this value to decrement from the value Initially assigned, but not to to am. MM 
valueXould change from one hop to another, the Checksum need to bo recalculated each time. 
SlJSSlare error menage we can see that the Checksum echoed .s miscalculated. 

...And again this is a Fragment Reassembly Time Exceeded 1CMP error message and not an 
ICMP Time Exceeded in Transit error message. 

The next example is with Novell Netware 5.1: 

[*ootGgodfather bi»]# hping2 -c 1 -x -y y-Y-Y-Y 
pnoo default routing interface selected {according to /proc) 
HPING y.y.y-Y (MpO Y-YY-Y): NO FIAGS are pet, 40 Headers + 0 data 
bytes 

Y>Y-Y*Y hp ing statistic - - - 
l packets tramitted,, 0 packets received, 100% packet loss 
round-trip min/avg/raax * 0,0/0, 0/0.0 tns 
[rootegodfather bin]# 

The Trace: 

20.12:28.008893 pppO > X.X.X,X.186S > y.y.y.y-0: • 
€87160929:667160929(0) win 512 (frag 5B586 ? 20®0+) (DF) (ttl 64) 

4500 0028 e4da 6000 4006 c236 xxxx aOtJOC 
yyyy yyyy 0749 OOOO 28f5 3e6l 669e 9fl5 
5000 0200 c5d2 0000 

20:12:41.313202 pppO < y.y«y-y > x.x.x.x: icmp: ip reaeaettbly time 
exceeded Offending pkt= [|tcpl (frag 5e5B6s20@o + ) (DP) [ttl 03 (bad 
ckaum d336l) (ttl 111, id 9591) 

4500 0038 2577 0000 6foi b28f yyyy yyyy 

XXXX 3QQCX ObOl b55f 0000 0000 4500 0028 
e4da 6000 0006 d336 xxxx xxxx yyyy yyyy 
0749 0000 28f5 3e61 

This unique pattern enables us to determine If the operating system In question Is a Novell 
Netware or other with one datagram only. 

6.19 The Precedence bite with ICNJP Error Messages (Identifying UNUX) 

Each IP Datagram has an 8-bit field called the TOS Byte", which represents the IP support for 
prioritization and Type-of-ServIce handling. 



Precedence 



TOS 



MBZ 



Figure 13: The Type of Servlca Byte 
The TOS Byte" consists of three fields. 
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The "Precedence field\ which is 3-bit long, is Intended to prioritize the IP Datagram. It has eight 
levels of prioritization 47 : 



Precedence " 


Definition 


0 


Routine (Normal) 


1 


Priority 


2 


Immediate 


3 


Flash 


4 


Flash Override 


5 


Critical 


6 


Internetwork Control 


7 


Network control 



Table 15! Precedence Field Values 



Higher priority traffic should be sent before lower priority traffic. 

The second field, 4 bits long, Is. the Type-of-Serv|ce* field. It Is Intended to describe how the 
network should make tradeoffs between throughput, delay, reliability, and cost In routing an IP 
Datagram. 

The last field, the "MBZ" (most be zero) r Is unused and most be zero. Routers and hosts ignore 
this last field. This field is 1 bit long. 



RFC 1 122 Requirements for Internet Hosts - Communication Layers, states: 
The Precedence field fe Intended for Department of Defense applications of the Internet 
protocols. The use of non-zero values In this field is outside the scope of this document and the 
IP standard specification. Vendors should consult the Defense Communication Agency (DCA) for 
guidance on the IP Precedence field and its implications for other protocol layers. However, 
vendors should note that the use of precedence will most likely require that Hs value be passed 
between protocol layers In Just the same way as the JOB field is passed". 

Other precedence information Is available wWh RFC 1812 Requirements for IP Version 4 Routers: 

"4.3.2.5 TOS-and Precedence 

... 

ICMP Source Quench error messages, If sent at all T MUST have their IP Precedence field set to 
the same value as the IP Precedence field In the packet that provoked the sending of the 
ICMP Source Quench message. All other ICMP error messages (Destination Unreachable, 
Redirect. Time Exceeded, and Parameter Problem) SHOULD have their precedence value set to 
6 (INTERNETWORK CONTROL) or 7 (NETWORK CONTROL). The IP Precedence value for 
these error messages MAY be settable". 

With the operating systems I have checked, nearly all of them used the value of 0x00 for the 
Precedence field (bits). 

All but LINUX 



47 RFC 791 - Internet Protocol, Hnpr//www.letf.org/rfc/fte791.txt. 
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Fyodor had outlined In his paper -Remote OS .Identification by TCP/rP 

that LINUX Is using the value of OxcO (an unused precedence value) as Us TOS byte value with 

ICMP Port Unreachable error messages. 

In the next example we have sent one UDP packet destined to port SOj^^^j* nSfux 6*1^* 
destination machine) from one LINUX machine to another, both running Redhat LINUX 6.1 . 

[rootostan /root] # hping2 -2 192-15915.5 50 1 

default routing not preaent k ^ , 0 dat _ 

OTING 192.158.5.5 (efchO 192 .168 .5.5) « udp mode set, 2B headers + 0 data 

ICMP%ort Unreachable , from 192,168.5.5 ifceimy. ays -security, com) 

192.168.5.5 hping statistic — T 
1 packets tramitted, o packets received, 100% packet loss 
round- trip min/avg/roax » 0.0/0.0/0.0 tns 

Kernel filter, protocol MA, raw packet socket 
Decoding Ethernet on interface ethO 

03/12-12:54:47.274096 192.168.5.1:2420 -> 192.168-5.5:50 
T3DP TTLs64 TOS: 0x0 ID: 57254 
Lea: 8 

03/12-12:54:47.274360 192.168.5.5 -> 192.168.5.1 
ICMP TTL:255 TOS : 0x00 ID:0 

DESTINATION UNREACHABLE: PORT UNREACHABLE 

00 00 00 00 45 00 00 1C DF AS 00 00 40 11 OF P4 B, 

CO A8 05 01 CO A8 05 05 09 74 00 32 00 08 6A El C.2..J. 

This abnormality with LINUX is not only limited to ICMP Destination Unreachable Port 
Unreachable error messages. 

Lets examine the next trace: 

00=30:08.339498 < X.X.x.x > y.y.y.y: ip-proto-72 0 (ttl 49, id 38624) 
4500 0014 96eQ 0000 3148 f4bf xxxx xxxx 

yyyy yyyy 

00:30:08.339559 > y.y-y.y > x.x.X>x ; icmp: y.y-YY P* ot °°°* 72 
unreachable Offending pkti x.x.x.x > y.y.y-y: ip-proto-72 0 intx ia 
38624) EtO0 OxcO] Cttl 255, id 37) 

45co 0044 0025 oooo ff oi bcdi yyyy yyyy 

xxxx xxxx 0302 fbla 0000 0000 4500 0014 

96e0 oooo 3148 f4bf xxxx xxxx yyyy yyyy 

0050 d909 621b 96f7 0000 0000 5004 0000 
df71 0000 

The ICMP error message pttduced by a LINUX machine based on Kernel ^ 4 ^2!SE? 
Unreachable Protocol Unreachable (Type 3 Code 2). As it can be seen the TOS Byte value that 
was used is again OxcO. Which la an unused Precedence bits value. 



w This feet was discovered by Fyodor. htte flwtfg^^ 
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LINUX embraced the behavior RFC 1812 suggested and sends all his ICMP error messages with 
the Precedence field value sent to OxcO (value of 6). 

Just to remind the reader - LINUX is not a router. 



6.20 TOS Bite (=field) Echoing with ICMP Error 

RFC 1394 Specify that an ICMP error message be always sent with the default TOS field value of 
OOOO (TOS field=TOS bits in the TOS Byte), 

When an offending packet with a TOS field value of 0000 Is eliciting an ICMP error message from 
an offended host, the TOS field value with all the operating systems I have checked will be set to 
0000. 

If we will pay attention to the TOS Byte we will see that LINUX and several routers will use the 
value of OxcO for the precedence field <see section 6.14 The Precedence bits with ICMP Error 
Messages for the explanation). 

What will happen if the TOS field with the offending packet will be set to a value different than the 
default (0000)? 

We will have several operating systems that will echo the TOS field back with the ICMP error 
message. 

Our first example is with an AIX 4.3 machine/where a UDP datagram is sent with a TOS field 
value of 0x10 hex: 

12=33;17. 319275 pppO > x.x.X,X, 2160 > Y-Y-Y-Y-Ot Udp 0 [toe 0x10] <ttl 
64, id 47349) 

4510 001C b8f5 0000 4011 9bea xxxx xxxx 

yyyy yyyy os7o oooo ooob disc 

12:33517, 614823 pppO < Y-Y*Y + Y > x.x.x.x: icrap: Y-Y-Y-Y U 4P P ort 0 
unreachable Offending pkt: x.x,x,x.2160 > y-Y-Y-Y-0? udp 0 [toe 0x10] 
(ttl 43, id 47349, bad cxsum aaeaO.fton 0x10] (ttl 241, id 17965) 
4510 003 8 462d 0000 flOl 5da£ YYYY YYYY 
X3cxx xxxx 0303 5470 0000 0000 4510 0030 

baf5 oooo 3111 aaea xxxx xxxx yyyy yyyy 

0870 0000 0008 0000 

As It can be seen from the trace, the TOS field value was echoed back by the AIX machine. This 
was tested against AIX 4.1 , 4.2.1 , 4.3, 4.3 tlx pack2. 



The next example is with DGUX 5.6: 

12:58:57.663517 pppO > x.x.x.x. 1074 > Y.y.y.y.ll: udp 0 [toa 0x8] {ttl 
64, id 47314) 

4508 001C bBd5 0000 4011 aQ37 xxxx xxxx 
yyyy yyyy 0432 000b 0008 d9el 

/ 

12:58:57, 984820 pppO < 134.210.1,200 * x.x.X.x, : iCTttpj y.y.y«Y-200 udp 
port 11 unreachable offending pkt: x.x.x,x.l074 > y.y-y>y."* udP 0 
[top QxB] (ttl 52, id 47314) [tos 0x8] {ttl 52, id 16984) 
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4508 O03B 4259 OOQD 3401 22a6 yyyy YYYY 
dSOB C41C 0303 f8b7 OODO 0000 4508 001c 

b8d2 oooo 3411 ac37 xxxx xxxx yyyy yyyy 

0432 000b 0008 0000 

How can WO differentiate between DGUX and AIX? If we will pay attention to the echoing 
Integrity. AIX 4.x sets the IP total length field value, with the echoed offending IP Header, to a 
value 20 bytes higher than the original. DGUX quote this field value correctly. 

The last operating system, which I have found echoing the TOS field value with its ICMP error 
messages, Is LINUX operating systems based on Kernel 2.2oc & 2.4 {the versions of the Kernel 
that I have tested): 



00:50:43^759906 pppO > x.x.x.x, 1952 > y.y-y.y-0: udp 0 [toe 0x10] (ttl 
64, id 15952) 

4510 OOlc 3e50 0000 4011 efib2 xxxx xxxx 
yyyy yyyy 07a0 0000 0008 a27f 

00:50:44.154556 pppO <: y.y.y.y > x.x.x.x: icmp: y.y.y.y.211 udp port 0 
- unreachable offending pkt: x.x.x.x.1952 > Y-y»y-y-Qs ^dp 0 £ to * 0x103 
(ttl 47, id 15952) [toe OxdO]. (ttl 238, id 54662) 

45do 0038 d5B6 0000 eeOi aOaf yyyy yyyy 

XXXX xxxx 0303 52d5 0000 0000 4510 001C 

3eS0 oooo 2fii f7b2 xxxx xxxx yyyy yyyy 

07a0 0000 0008 a27f 

Another unique pattern with LINUX Is setting the Precedence field value to OxcO with ICMP error 
messages. This helps us to differentiate LINUX from the other operating systems that echo the 
TOS fieW value. 

While LINUX embraced RFC 1812 instructions for routers regarding the TOS and Precedence 
fields, the other operating systems that echo the TOS field value don't seem to have a good 
excuse for doing so. 



6.21 DF Bit Echoing with ICMP Error Messages 

We already have the DF Bit Echoing method with ICMP Query message types (& Replies); I was 
thinking why this couldn't happen with ICMP Error Messages as well? 

What will happen if we will set the DF bit with an offending packet that will generate an ICMP 
Error message? Will the DF Bit be set with the ICMP Error Message? 

In the next example, a UDP datagram Is sent to a closed UDP port, to ©licit an ICMP Port 
Unreachable error message. The DF bit is set with the offending datagram. As it can be seen the 
DF bit is set with the ICMP error message the FreeBSD 4.1.1 machine, which was the target 
system Issued back. 

[rootegodfather /root J # hping2 -2 -p 2000 -c 2 -y y-y.y-y 
pppO default routing interface selected {according to /proc) 
hping y.y.y-y (pppq y*y*y.y) 2 ud P wode Bet * 28 headers + 0 data by^ 3 

ICMf Port Unreachable from y.y.y.y (bost_addre3e) 
ICMP Port Unreachable from y-y-y.y (bost_address) 

y.y.y.y hping statistic 
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2 packets tramitted, 0 packets received, 100% packet loss 
round- trip min/avg/max - 0*0/0,0/0.0 TXtS 
[root@godfatlier /iroot]# 

0Os31:29.SO5075 pppO > x,x.x.x.l403 > y.y .y.y_2000 : udp 0 (DF) (ttl G4, 
id 19417) 

4500 001c 4bd9 4000 4011 452b xxxx xxxx 
yyyy yyyy 057b 07d0 0008 48c6 

00:31:30.103692 pppO < 18,170.1,79 > x.x.X.X: icmp: y>y-y.y udp port 
2000 unreachable Offending pkt: x,x,x.x.!403 > y.y .y .y.2O00; udp 0 (DF) 
.{ttl 5 45 f id 19417) (DP) (ttl 238,, id 47017) 

45Q0 003a b7a9 4000 eeoi 2b4e yyyy yyyy 
xxxx xxxx 0303 efa9 0000 0000 450 0 001c 
4bd9 4000 2dll 532b xxxx xxxx yyyy yyyy 
0S7b 07d0 0008 0000 

We can distinguish between the group of operating systems, which win echo back thB DF bit with 
their replies, to the group of operating systems that will not 

The next example is with Microsoft Windows ME: 

00:49:45.853751 pppO > x.X.x.x.1580 > y.y,y.y.l0: Udp 0 (DF) (ttl $4, 
id 63227) 

4500 001c fSfo 4000 4011 730a xxxx xxxx 

yyyy yyyy 062c oooa oooo 2$dd 

00:49:46.173681 pppO < 212.150.102.96 > X.X.X.X: icmp: y.y«y.y udp port 
. 10 unreachable Offending pkt: x*x.x*x,1580 > y.y.y.y.10: udp 0 (DF) 
(ttl 55, id 63227) (ttl 119, id 430) 

4500 0038 oiae oooo 7701 714c yyyy yyyy 

xxxx xxxx 0303 cdel 0000 0000 4500 001c 

f$fb 4000 3711 7c0a xxxx xxxx yyyy yyyy 
062C oooa 0008 20dd' 

Among the operating systems I have checked LINUX machines based on Kernel 2.2.x/ 2.4 jc, 
ULTRIX. Novell Netware, and Microsoft Windows 98ra8SE/ME/NT4SP6A/Windows 2000 Family, 
will not echo back the DF bit with their ICMP Error messages. 

How can we distinguish between tha operating systems In the non-DF echoing, group? 

Since Unux is using the value of OxcO hex for his Precedence Bits field value for all ICMP Error ■ 

messages we can separate it instantly. 

00:25:17.203727 pppO > x.x.x.x.1421 > y .y .y ,y. 2000 : udp 0 (DF) (ttl 64, 
id 1196S) 

4500 001c 2ecl 4000 4011 b93S XXXX xxxx 
yyyy yyyy 058d 07d0 ooob 9fa9 

00:25:17*573696 pppO < y-y.y-y > x.x»x.x: icmp: y.y-y-y Udp port 2000 
unreachable Offending pkt: x.x.x.x.1421 > y.y.y.y.2000x udp 0 (DP) (ttl 
45, id 11969) [top OxcO] (ttl 236, id 38250) 

45c0 0038 956a 0000 ecOl e5c2 yyyy yyyy 
XXXX XXXX 0303 4fee 0000 0000 4500 001C 

2ecl 4000 2dii cc3B xxxx* xxxx yyyy yyyy 
058d 07d0 0008 9f*9 
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ULTRIX echo integrity is not that good. The offonding packet echoing will set both the IP Header 
Checksum and the Original UDP Checksum to zero. It will also miscalculate the IP ID field value 
and will flip the first 8 bits with the second one, creating a false value for it: 

00:29:05.013726 pppO > X.X.X.x. 1188 > y .y.y ,y,200Q : V3p 0 (DP) (ttl 64, 
id 34921) 

4500 001c 4000 4011 5f85 XXXX xaoOC 

yyyy yyyy 04a4 Q7d0 0008 aOS7 

00:29:05.383686 pppQ < 194.47.250*222 > x.X.x.x: icmp; y.y-Y*y udp port 
2000 unreachable Offending pkt; x.x.x.x. 1I8B > y.y.y .y,2000 : udp 0 (ttl 
45/ id 27016:, bad cfceum oi) (ttl 236, id 9736) 

4500 0O38 2608 oooo ecOi 55da yyyy yyyy 
xxxx xxxx 0303 Cle7 OOOO 0000 4500 001c 
$388 0000 2dll 0000 xxxx xxxx yyyy yyyy. 
04a4 07d0 000$ 0000 . 

Trite will leave us with Novell Netware and the various Microsoft Widows Operating Systems. 

As discussed in section 6.17 "Nov©// Netware Echoing Integrity Bug with ICMP Fragment ^ 
Reassembly Time Exceeded *, when a Novell Netware operating system issue an ICMP Time 
Exceeded error message it will zero out on the echoed offending pocket the IP TTL field value. 
We will use this information and send an offending packet to the questioned operating systems 
that will elicit an ICMP Time Exceeded error message from the quesftoned OSs. 

Offending Packet wtth PP eh sot 
(data portion eet to 70 byte*, for example) 

© / \ 

. Roply-Ent* / \ Reply -Error 

Message not / \ Mewagejchcrtng 

Echoing tneCJf Bit / \ thoDFBK 

LINUX b wed on Kernel 2.2.* 2.4X °s* 

ULTRIX 
Novell Netware 
HPUX 
Vwndow 06/d&SE/ME 
Microsoft Window* NT* Server, SP6a 
Microsoft WndOWa 2000 Family 

/\ &4 bytes of tha 

Wong IP ID \ offending pdtftft 

IP Header Ch^bTem \ V. daWport^rB 

Original ChMfcumlazBro \ echoed back 

UNUX Kernel band 2.2.x. 2.4X ULTRIX ^L^Sur ^ . 

Microsoft Windows NT4 Server. 5P6b 
MlcrOttn Wndows20M Family 

® Offending Packet thetwIH elicit ICMP Time Exceeded 
&ror Maaaage 



Reply with echoed / \ Reply wllh Etfioed 

IP TTL field 1=0 / \ IP TTL Field =0 



Window* Be798$E/ME fl 
M icrocoft Window*!*™ Server. SP6a r,otwam 
Microsoft Windows 2000 Family 

Diagram 12: DF Bit Echoing wirh ICMP Error Messages 
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Wo can take a second approach using the ICMP Fragment Reassembly Time Exceeded error 
message. We will send an offending packet with the DF bit set that will elicit an ICMP Fragment 
Reassembly Time Exceeded error message back from the targeted machine, Novell Netware, 
LINUX based Kernel 2J2jc and 2.4x-t, and the various Microsoft Windows operating systems will 
set the DF bit with their replies. LINUX and Novell have their unique fingerprinting with ICMP 
Fragment Reassembly Time Exceeded error messages, enabling us to Isolate the Microsoft 
based operating systems machines. 



HP-UX 11 .x based machines will have a unique behavior when the PMTU discovery process 
based on ICMP Echo Requests Is enabled (by default). In the next example I have sent a UDP 
datagram to port 53 (DNS) of the targeted HPUX machine. 

[rootagodfather /root] # hping2 -2 -p 53 -c 2 -y y.y*y«y 
pppQ default routing Interface selected (according to /proc) 
HPING y,y T y*y (pppO y.y.y.y) : udp mode set, 2B headers +.0 data bytes 
ICMP Port Unreacixable from y-y-y-y (unknown host name) 
ICMP Port Unreachable from y.y.y.y (unknown host name) 

y«y.y»y kping statistic — * 

2 packets tramitted, 0 packets received, 100% packet loss 
round- trip min/avg/max =* 0.0/0.0/0*0 ras 
[rootagodf ather /root) # 



00:45:02.490445 pppo > x .x.x.x. codasrv > y.y.y.y. domain: o [oq] (o) 
(DF) (ttl 64 , id 7454) 

4500 001c Idle 4000 4011 e708 xxxx xxxx 

yyyy yyyy 0980 0035 oooe 

As an instant reply the PMTU discovery process which is based upon ICMP Echo requests) Is 
started: 

00:45:03,113^86 pppo < y-y-y-y > x 4 x.x,x: icmp: echo request (DF) (ttl 

243, id 2S153) 



4500 


OSdc 


6241 


4000 


f201 


ea34 


yyyy 


yyyy 


XXXX 


xxxx 


0800 


7e52 


9abc 


defo* 0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 


0000 
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0000. 


0000 


0000 
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DOOQ ODDO OOOO OQOO OOOO OOOO 0000 0000 
0000 OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO- OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OQOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO QOOO OOOO OOOO OOOO 00-00 OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO 0,000 OOOO 
oobb OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OQOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OQOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO QOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OQOO OOOO 
.0000 OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO oooo 
OOOO 0000 OOOO 0000 OOOO 0000 OOOO OOOO 
OOOO OOOO OOOO OOOO DQOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO QOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO QQOQ OOOO OOOO OQOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 
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My LINUX machine replied with ICMP Echo Reply: 

00:45:03.113767 pppO =» x.x.x.x > y.y.y.y: lamp z echo reply (ttl 255^ id 
98) m 
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0000 0000 0000 0000 0000 0000 0000 0000 
0000 oooo oooo 0000 OOOO 0000 

The first IC|WP Port Unreachable error message arrives without the DF btt set: 

00:45:03 ,123692 pppo < y.y.y,y > x.x.x.x: icmp: y*y.y«Y udp port domain 
unreachable Offending pkt; x.x.x,x,codaprv > y.y.y. y. domain: 0 [0q] , (0) 
<DF) (ttl 51, id 7454) (ttl 242, id 25154) 

4500 0038 6242 0000 f201 2fds yyyy yyyy 
xxxx xxxx 0303 33cl 0000 0000 4500 001c 
Idle 4000 3311 £408 xxxx xxxx yyyy yyyy 
0980. 0035 0008 bf7e 

A second UDP datagram is sent 

1)Os45:03.4S3752 pppo > x.x.x.x.coda^rv-se > y.y.y.y. domain:. 56B10+ (0) 
(DF) (ttl 64, id $$904) 

4500 001c eaOO 4000 4011 la26 XXXX XXXx 
yyyy yyyy 0981 0035 0008 bf 7d 

The ICMP Port Unreachable error message that was sent for the second UDP datagram now sets 
the DF bit as part of the PMTU discovery process maintenance: 

00:45:03. B13687 pppo < y-Y-Y-Y > x^x.x.x: icmp: Y-Y-Y-Y ud P po^rt domain 
unreachable Offending pktt x.x.x,x.codaBrv-Be > y.y.y.y .domain: 26990 
op5* [b2&3=0x2d61] [29188a] [25700q] [24946n] I28769au] (0) (DF) (ttl 
51, id 59904) (DF) (ntl 242, id 25155? 

4500 0038 6243 4000 f201 efdS yyYY YYYY 
XXXX XXXX 0303 33cl 0000 0000 4500 001C 

eaoo 4000 3311 2726 xxxx xxxx yyyy yyyy 
0981 0035 0008 bf7d 

This also means that with the regular behavior wfth HPUX 1 1 .x it will not echo back the DF bit 
Also, If you are sending only one offending datagram to the targeted HPUX 1 1 *x based machirte, 
you will not be able to see the change. 

So how can we distinguish HPUX from the other operating systems? 

HPUX based operating systern(s) machines will echo up to 64 bytes of the offending packet's 
data portion. By sending a bigger offending datagram (for example with BD bytes of data portion) 
we can examine which of the operating systems In question, which do not set the DF bit with, the 
ICMP error message, will echo 64 bytes of the data portion (or even more than 8 and will not set 
the the precedence bits to OxcO). 
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Not that useful fingerprinting method(s) 
6.22 Unusual Big ICMP Echo Request 

What would happen if we would send unusual big ICMP Echo message that would require Its 
fragmentation? Would the queried operating systems will process the query correctly and 
produce an accurate reply? • k 



[root©aik /root]# ping -s 1500 x^x.x.x 

112 

CopyrlQht © Ofr Alton. 2000-200t 

PAGE 1 66/209 * RCVD AT 7/112004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 " DNIS:7469694 * CSID:9497609502 " DURATION (mm-ss):5746 



Jun-30-2004 09:47pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-702 P. 063/1 05 F-610 



o n 

I CMP Usago En Scanning 
Veraron2.5 

PING x.x.x.x (x.x.x.x) from y»y-y.y : 1500(1528) bytes of data. 

1508 byte* from x.x.x.X: iCifl£_ee<£=Q ttl=*241 time=1034.7 ras 

1508 bytes from hoat_address (x.x.x.x) ; icmp_seq=2 ttl=241 tiraeal020>0 

me 

1508 bytes from hOBt_addreas (x.x.x»x) ; icmp_seqB3 tt 1-241 time-1090 *4 
ins 

1508 byte3 from host_address (x.x.x.x) : icinp_seq«5 ttl-241 timealOSO.O 
ms 

x.x,x.x ping statistics 

8 packets transmitted, 5 packets received, 37% packet loss 
round-trip min/avg/raax 1000 ,2/1041 . 0/1090 .4 ms 
[rootoaik /root]# 



As it seems all the probed operating systems I have tested behaved correctly processing the 
query and sending the reply back. 

What else can assist us with this kind of query? 
The DF (Don't Fragment) bit 

Some operating systems would process the query and set the don't fragment bit on the fragments 
of the reply like we have outlined fn the "DP Bit Playground" section. These operating systems 
would be Sun Solaris, and HP-UX 1 0.30 & 1 1 .Ox 49 . 

We can use other methods, which does not generate the kind of noise this method generates. 
Basically there is no reason for this size of ICMP Echo request This shouid trigger IDS systems 
immediately that something suspicious is happening. 



Please refer to section Q.2 for mora Information. 
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7.0 Filtering ICMP on your Filtering Device to Prevent Scanning Using ICMP 
7-1 Inbound 

An example of incoming ICMP traffic that should be blocked in order to prevent scanning 
techniques that were outlined in this paper might be: 

• ICMP Echo (used for Most Detection, traceroute, Inverse Mapping, and Operating 
System Fingerprinting) fc 

• ICMP Echo Reply (used for Inverse Mapping) 

• ICMP Time Stamp Requests (used for Host Detection, Operating System 
Rngerprlnting). 

• ICMP Address Mask Request (used for Host Detection, Operating System 
Fingerprinting) 

• All ICMP Message Types (Inverse Mapping Technique) 

• ICMP Error messages (Operating System Fingerprinting) 

• All ICMP Message Types should be blocked in order to prevent the fingerprinting 
techniques I have outlined in this research paper. 

• You should also block the IP directed broadcast on your border router. 

• Deny access to your Broadcast and Network addresses from the Internet 



If you look closely at this list, it is all ICMP Message types, whether query types or error types. 



7*2 Outbound 

There are people who claim that any traffic type of ICMP should be allowed from a protected 
network to the Internet This is not true. Filtering the incoming traffic does not mean we are 
protected from some of the security hazards f outlined in this paper. 

7.2.1 ICMP ECHO Reply (Type 0) 

Used to map a host using Host Detection. 



•7.2.2 ICMP Destination Unreachable Messages 

. I have demonstrated that host detection can be done with bad IP Header packets, which elicit 
various ICMP Parameter Problem and ICMP Destination Unreachable error messages from the 
probed machines and draw the attacked network topology. 



7.2.3 ICMP "Fragmentation Needed and Don't Fragment Bit was Set" 
See Section 3.5 



7.2.4 ICMP ECHO Hype 8) 

We have to have a Stateful filtering device that would perform Stateful Inspection with ICMP In 
order to let ICMP ECHO Requests out, and receive only the corresponding ICMP ECHO Replies. 

The current state with filtering devices is not that bright Most of them do not perform Stateful 
inspection with the ICMP protocol. Allowing ICMP ECHO Replies inside our protected network is 
very dangerous and is not worth it 

Unless you use a Stateful filtering device with the ICMP protocol don't let ICMP ECHO Replies 
into your protected network. This would make your requests useless so you better Wock them. 
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7.2.5 ICMP Time to Live Exceeded In Transit (Type 1 1 Code 0) 

To eliminate traceroute and Reverse Mapping techniques we do not want to let a Time-to-Uve 
Exceeded code 0 messages go back to the malicious computer attacker. 

7.2.6 ICMP Fragmentation Reassembly Time Exceeded fType 11 Code 1) 
By blocking this ICMP type we eliminate the usage of a Host Detection technique, which sends 
only few fragments* form a fragmented datagram, and force the probed host to send us an ICMP 
Fragmentation Reassembly Time Exceeded error message back revealing his existence. 



7.2.7 ICMP Parameter Problem 

We have demonstrated that host detection can be made with bad IP Header packets, which 
would elicit various ICMP Parameter Problem and ICMP Destination Unreachable error 
messages from the probed machines. 



7.2.8 ICMP Time Stamp Request & Reply 

Time Stamp requests & replies can be used for Host Detection and Inverse Mapping. 



7.2.9 ICMP Address Mask Request and Reply 

Address Mask request & reply can be used for host detection and Inverse Mapping. 



7.2.10 The liability Question 

System administrator / Network administrator don't want to be held liable for an attack generated 
from there network by an abusive user (or a malicious computer attacker using a compromised 
system within the network). Therefore blocking some types of ICMP traffic from the protected 
network to the outside world Is recommended for liability reasons: 

a Destination Unreachable Codes 2-4 

o ICMP Destination Unreachable error messages 2-4 ("Port Unreachable", 
-Protocol Unreachable" and "Fragmentation Needed and DP Flag was Set") Is a 
group of messages that are hard error conditions and when received should 
terminate a connection- 

This allow an attacker to send fete Destination Unreachable codes 2-4 to 
terminate valid connections between the attacked target and other hosts on the 
void. 

Old TCP/IP Implementations terminal TCP connections when receiving 
those error messages* Modem TCP/IP implementations no longer terminate a 
TCP connection when receiving those error messages 

o Source Quench messages 

o Since hosts still react to Source Quenches, by slowing communication, they can 
be used as a Denlal-of-Service measure. 

o Redirect messages 

o If you can forge ICMP Redirect packets, and if your target host pays attention to 
them - ICMP Redirects may be employed for denial of service attacks, where a 
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host is sent a route that loses it connectivity, or fs sent an ICMP Network 
Unreachable packet telling it that it can no longer access a particular nelwork. 



This means that all outbound ICMP traffic should be disallowed. 



7.3 Other Considerations 

If you want to maintain strong ICMP filtering rules with your Firewali/Rltering-Device I suggest 
you block all Incoming ICMP traffic except for Type 3 Code 4, which is used by the Path MTU 
Discovery process . ICMP Type 3 Code 4 Should be allowed from the Internet to your DMZ at 
least Opening your Internal segmentation to this kind of traffic is questionable and depends on 
the facilities / activities / usage of the site and the level of filtering you wish to maintain. 

If you will block Incoming ICMP "Fragmentation Needed and Don't Fragment Bit was Set" your 
network performance will suffer from degradation. You should understand the security risks 
involving. In opening this kind of traffic to your DMZ (& protected network) - The possibility of a 
Denia^of-Servfce, Inverse Mapping, Host Detection, and a one-way Covert communication 
channel (which was not been seen in the wild yet). 

Another consideration could be the usage of network troubleshooting tool's such as traceroute . 
and ping. In the case of traceroute if the filtering device you are using does not support Stateful 
inspection with ICMP than allowing ICMP TTL Exceeded In Transit (Type 1 1 . code 0) error 
messages Inside the protected network could lead to various security hazards. The same goes 
with ping, where ICMP ECHO reply is even more dangerous when allowed inside the protected 
network (Inverse Mapping, Covert Channel and more security risks). 

You can limit the number of systems that need to use the network troubleshooting tools with ACL, 
but bear in mind that those systems could be mapped from the Internet - and this is only the tip of 
the Iceberg, 




Internal Hos tfe) performance considerations - Whan blocking incoming ICMP Destination 
Unreachable Network/Host/Protocol/Port Unreachable ICMP error messages coming from the 
Internet, host(s) would hang when the destination system's network is unreachable/when a host 
is unreachable/when a protocol on the destination machine is not available/a port on a destination 
machine Is closed. They all would hang; until the timeout counter would reach zero. This HWe 
Inconveniently is better than having the dangers other types of ICMP error messages inside your 
network can introduce. 



Unless your filtering device is a real intelligence one, doing his work with dynamic tables and 
correlating correctly the ICMP replies with the requests, do not open your Internal network 
segment to no ICMP traffic type. 

Some might offer to use a Proxy server with the ICMP protocol between the Internet and you 
protected network(s). A Proxy Server fe only a tunnel - remember that 



See Appendix B: "Fragmentation Needed but the Dont Fragment BJt wag ?er and the Path MTU Discovery Process. 
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Rflum 14: Firewall ICMP Filtering Rules 

7.4 Other Problems - Why it is important to filter ICMP traffic in the Internal 
segmentation 

Consider the following realistic scenario; 

You have an Internal segment built with Microsoft based operating system machines (for the sake 
of the example only). A malicious computer attacker might send you a Trojan that will have Host 
detection and/or mapping capabilities* It will be hidden in an Email message (either as attachment 
or some other thing) a naTve user will open. After activation it will start to map Interna! hosts and 
internal segments and send the information back to the malicious computer attacker. 

What will be the easiest method in order to map internal host(s)? Ping them. 

How many of you reading this research have "management segments" that are allowed to use the 
Ping utility In order to verify that some Hosts are alive? 

If something like this Trojan gets Its way to this segment than probably your entire Internal 
networking infrastructure (or the Important part of it) will be revealed. 

Some one might think that strong filtering or a good ant! virus might help - forget it I have seen 
people separating their work environment to more than two or three computers, but they always 
use the Email, and need to surf the web,., (good ways to send the collected Information out). 

My suggestion is to configure internal host(s) not to answer for ICMP Query message types they 
should not answer for. I would restrict this to the maximum and not allow internal hosts to be 
queried with any ICMP Query message type. 
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Back to our monitoring problem - if you need to maintain management/monitoring capabilities, 
than 1 would suggest filtering the traffic In both ways from the management stations to the 
monitored systems In a way it would not be possible to simply query the last (dynamic filtering / 
stateful filtering with ICMP)> Use a dedicated system for the querying and block the other 
machines in the management segment from do|ng so* 



Infernal Nrtwoi* -> Othar segments / IntaiNt 
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Rgure 1S: Internal segmentation ICMP Filtering Example 



7.5 The Firewall 

It Is extremely Important to block traffic which is aimed at the Firewall itself* This rule will not 
block everything. For example, ICMP error messages the firewall generates for various stimulus. 

Some firewalls will hold a certain portion of a fragmented packet until the IP Header and the 
underlying protocol's header arrives. The ICMP error message for Fragment Reassembly Time 
Exceeded will not be of the Host It will be of the Firewall spoofing it Some Firewalls has the 
ability to spoof ICMP Echo Replies for Hosts they are defending. We will have the opportunity to 
fingerprint the operating system, which the firewall software is Installed oh. 

We will gain an extremely important ability. Therefore it is recommended to have two basic rules 
when you configure your firewall's rule base. The first is to deny any traffic destined to the firewall 
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and the second would be to deny any error messages (or other conditions such as TCP reject 
etc.) that might help a malicious computer attacker In his task to fingerprint the Firewall itself. 
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8.0 Conclusion 

The ICMP protocol is a very powerful tool In the hands of smart malicious computer attackers. 
Mapping, detecting, and fingerprinting of hosts and networking devices can be done in various 
ways as 1 have outlined In this paper; 

It Is extremely important to understand that ICMP traffic can be used for other malicious activities 
other than scanning, such as: 

• Denial of Service Attacks 

• Distributed Denial of Service Attacks 
« Covert Channel Communications 

Therefore filtering Inbound and Outbound ICMP traffic Is very important and may help you in 
preventing risks to your computing environment 
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Appendix A: The ICMP Protocol 51 

Internet Control Message Protocol (ICMP) is used for two types of operations: when a router or a 
destination host need to inform the source host about errors in a datagram processing, and for 
probing the network with request messages in order to determine general characteristics about 
the network (getting the information back, hopefully, with the reply messages). 

Some of tCMP's characteristics are; 

o ICMP uses IP as if it were a higher-level protocol, however, ICMP is already an internal 

part of IP, and must be implemented by every IP module* 
o ICMP is used to provide feedback about some errors fn a datagram processing, not to 

make IP reliable. Datagrams may still be undelivered without any report of their loss. If a 

higher level protocol that use IP need reliability he must implement it. 
o No ICMP messages are sent in response to ICMP messages to avoid infinite repetitions. 

The exception is a response lo ICMP query messages (ICMP Types 0,8-10,13-18. See 

Table 1 1CMP Query Messages), 
o For fragmented IP datagrams ICMP messages are only sent about errors on fragment 

zero (first fragment). 

o ICMP error messages are never sent in response to a datagram that is destined to a 

broadcast or a multicast address, 
o ICMP error messages are never sent In response to a datagram sent as a link layer 

broadcast. 

o ICMP error messages are never sent in response to a datagram whose source address 
does not represents a unique host - the SQUrce IP address cannot be zero, a ioopback 
address, a broadcast address or a multicast address. 

o ICMP Error messages are never sent in response to an IGMP massage of any kind. 

o When an ICMP message of unknown type is received. It must be silently discarded. 

q Routers will almost always generate ICMP messages but when it comes to a destination 
host(s), the number of ICMP messages generated Is Implementation dependent 



JCMP Query Messages • 


. ICMP error Messages 


Echo 

Router Advertisement 
Router Solicitation 
Time stamp 
Information 
Address Mask 


Destination Unreachable 
Source Quench 
Redirect 
Time Exceeded 
Parameter Problem 



Table 16; ICMP message types 



f 



ICMP Is described In RFC 972 Mp://wv^,tetf.ori3/ffc/rfcQ972.b(t) with updates in: RFC 896 (Source Quench), RFC 950 
(Address Mask Extensions), RFC 1191 (Path MTU Discovery) A RFC 1256 (Router Discovery). Further clarifications 
dbout the ICMP protocol are fcysluded in RFC 1 122 and fn RFC 1 012. STD 2 has redefine and clarified much of ICMP's 
core functionality. 
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A.1 ICMP Messages 

ICMP messages are sent in IP datagrams. The protocol number wfH be always on© (ICMP), and 
the Type-of-Sen/lce will bo zero. The IP data field will contain the actual ICMP message: 



IP Data 

Flutt 



"4« 



4 ha 
Nndir 

Ljnpjh 



e-Mtypoefwwvten 



Wtit MmUIIhI on 



ITU) 



(ICMP) 



total length tin &yt») 



3UI 



iMiFaomoiuomn 



1WHbomkiro»]iKl»tjni 



OptiORf ( IT any ) 



ICMP data (dapftndfhg on th t type 4 innm0o} 



I 



Figure 16: ICMP Message Format 



ICMP error message length 

Every ICMP error message includes the Internet (IP) Header and a* teas* the first B data octets 
(bytes) of the datagram that triggered the error; more than 8 octets (bytes) may be sent; this 
header and data must be unchanged from the received datagram. 

The TYPE field specifies the type of the message, while the error code for the datagram reported 
on by this ICMP message is contained In the CODE field. The code interpretation is dependent 
upon the message type* 
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-Type- 


: - ; ' , . Name' . 


Code j 


0 


Echo Reply 


0 No Code 


1 


Unassorted 




2 


Unassigned 




3 


Destination Unreachable 62 


0 Net Unreachable 

1 Host Unreachable 

2 Protocol Unreachable 

3 Port Unreachable 

4 Fragmentation Needed and Don't 
Fragment wad Set 

5 Source Route Failed 

6 Destination Network Unknown 

7 Destination Host Unknown 
3 Source Host Isolated" 






9 Communication with Destination 
Network is Administratively Prohibited 










10 Communication with Destination Host Is 






Administratively Prohibited 65 






1 1 Destination Network Unreachable for Type of 






Service. 






12 Destination Host Unreachable for 






Type of Service, 






13 Communication Administratively Prohibited. 






14 Host Precedence Violation 






15 Precedence cutoff in effect 


4 


Source Quench 


0 No Code 


I 5 


Redirect 


0 Redirect Datagram for the Network (or subnet) 

1 Redirect Datagram. for the Ho3t 

2 Redirect Datagram for the Type of Service and 
Network 

3 Redirect Datagram for the Type of Service and 
* Host 


6 


Alternate Host Address 


0 Alternate Address for Host 


7 


Unasslgned 




8 


Echo Request 


0 No Code 


9 


Router Advertisement 


.0 No Code 


10 


Router Selection 


0 No Code 


11 


Time Exceeded 


0 Time to Live exceeded in Transit 

1 Fragment Reassembly Time Exceeded 


12 


Parameter Problem 


0 Pointer indicates the error 

1 Missing a Required Option 

2 Bad Length 


13. 


TImestamp 


0 No Code 


14 


Timestamp Reply 


0 No Code 



52 RFC 972 defines codes 1-5. RFC 1122 defines codes $-12. RFC 1612 defines cades 1&-15. 

53 Reserved for usa by U.S. milfteiy agencies. 

54 Reserved for use by U.S. military agencies. 

55 Reserved far use by U.S. mflltory agencies. 
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-:: Code . 


Type 


Name 


15 


Information Reauest 


0 


No Code 


iO 


Infrnm^-KriKt R(S»n!v 

iniLJiiiiauuN rvojjjy 


0 


No Code 


* l / 




0 


No Code 


1A 


AHHm^Q Mask Reolv . 


0 


No Code 






0 


No Code 




20-29 reserved 


(for Robustness Experiment) 


30 


TraceroLrte 






31 


Datagram Conversion Error 






32 


Mobile Host Redirect 






33 


IPv6 Where-Are-You 






34 


IPv6 l-Am-Here 






35 


Mobile Registration Request 






•36 


Mobile Registration Reply 






39 


SKIP 






40 


Photuris 










0 


Reserved 






1 


unknown security parameters index 






2 


valid security parameters, but authentication 








failed 






3 


valid security parameters, but decryption failed 



TaWe 17: ICMP Types & Codes 

Checksum - contains the 16brt one's complement of the pne's complement sum of the ICMP 
' message starting with the ICMP Type field. For computing this checksum, the checksum field is 
assumed to be zero. 



Data 



With ICMP error messages it will contain a part of the original IP message for which this 
ICMP message was generated* The length of the DATA field equals the IP datagram 
length less the IP header length. Every ICMP error message Includes the Internet (IP) 
Header and at least the first 8 data octets (bytes) of the datagram that triggered the error; 
more than 8 octets (bytes) may be sent; this header and dgta must be unchanged from 
the received datagram. ; 

With ICMP query messages the Data field will contain dependent Information upon the 
query type. 



A.1 1CNIP Error Messages 

ICMP error messages are used to report a problem that prevented delivery. The nature of the 
problem should be a non4ranslent delivery problem. 
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Q 4 ft 



1B 



31 



Typo 



IPhowJor+64hfci£* original data of tto datagram 



4 byteft 
4faytea 



Figure 17: ICMP Error Message Genera! Format 



ICMP error message length 

Every ICMP error message Includes the IP Header (20 to 60 bytes) and at least the first 8 data 
bytes of the datagram that triggered the error more than 8 bytes may be sent; this header and 
data must be unchanged from the received datagram. 

AN ICMP error message length should be between 36 to 72 bytes. 

The ICMP Protocol Rules for ICMP Error Messages 

» ICMP Error messages are not sent for another ICMP Error message to prevent Infinite 
loops. 

• ICMP error messages are never sent In response to a datagram that is destined to a 
broadcast or a multicast address. 

• ICMP error messages are never sent fn response to a datagram sent as a link layer 
broadcast 

• ICMP error messages are never sent In response to a datagram whose source address 
does not represents a unique host - the source IP address cannot be zero, a loopback 
address, a broadcast address or a multicast address. 

■ ICMP Error messages are never sent in response to an 1G MP massage of any kind. 

A.1.1 ICMP Error Messages 6 * 

• Destination Unreachable (Type 3) 

• Source Quench (Type 4) 

• Redirect (Type 5) 

• Time Exceeded (Type 11) 

• Parameter Problem (Type 12) 



A.1.1.1 Destination Unreachable (Type 3) 

ICM P Destination Unreachable message type Issued by a Destination Host: 
A destination host issues a destination unreachable message when the protocol specified in the 
protocol number field of the original datagram Is not active on the destination host or the 
specified port Is inactive. 



ICMP Destination Unreachable message type Issued by a Router: 



Some of the wording fn this section ere direct quotes fn*n RFC 792 available from Wpjh^M.QWMW^Q™-**. 
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A router issue a destination unreachable message In response to a packet that it cannot forward 
because the destination (or next hop) Is unreachable or a service is unavailable. 



Code 



Meaning 



Explanation 



4 
5 
6 

7 
8 
9 

10 

11 

12 

13* 

14 



Network Unreachable 
Host Unreachable 

Protocol Unreachable 

Port Unreachable 



Fragmentation needed and 
DF flag Set 
Source Route Failed 



Destination 
Unknown 



Network 



Destination Host Unknown 

Source Host Isolated 

Communication with 
Destination Network is 
Administratively Prohibited 
Communication with 
Destination Host is 
Administratively Prohibited 
Network Unreachable for 
Type pf Service 

Host Unreachable for Type of 
Service 

Communication 
Administratively Prohibited 

Host Precedence Violation 



Generated by a router if a route to the destination 
network is not available. 

Generated by a router if a route to the destination host 
on a directly connected network is not available (does 
not respond to ARP). 

Generated If the transport protocol designated In a 
datagram is not supported in the transport layer of the 
final destination. 

Generated if the designated transport protocol (e.g, 
UDP) Is unable to demultiplex the datagram In the 
transport layer of the final destination but has no 
protocol mechanism to inform the sender. 
Generated if a router needs to fragment but cannot 
since the DF flag is set. 

Generated If a router cannot forward a packet to the 
next hop in a source route option. 
According to RFC 1812 this code should not be 
generated since "rt would imply on the part of the router 
that the destination network does not exist (net 
unreachable code 0 should be used instead of code 6). 
Generated only when a router can determine (from link 
layer advice) that the destination host does not exist 
Generated by a Router If It have been configured not to 
forward packets from source. 

Generated by a Router if it has been configured to 
block access to the desired destination network. 

Generated by a Router If it has been configured to 
block access to the desired destination host 

Generated by a router if a route to the destination 
network with the requested or default TOS is not 
available. 

Generated if a router cannot forward a packet because 
Its route(s) to the destination do not match either the 
TOS requested in the datagram or the default TOS (0). 
Generated If a router cannot forward a packet due to 
administrative filtering (ICMP sender is not available at 
this time). 

Sent by the first hop router to a host to indicate that a 
requested precedence is not permitted for the particular 
combination of source/destination host or network, 
upper layer protocol, and source/destination port 
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Code 


Meaning . . 


Explanation ( ' / 


15 


Precedence cutoff In effect 


Tbe network operators have Imposed a minimum level of 
precedence required for operation, the datagram was 
sent with precedence below this level. 



* Routers may have a configuration option that causes code 13 messages not to be generated. 
When this option is enabled, no ICMP error message Is sent In response to a packet that Is 
dropped because it's forwarding te administratively prohibited. Same Is with type 14 & 15. 

Table 18: Destination Unreachable Codes (Router) 

The only type of ICMP Destination Unreachable error message, which Is slightly different from the 
other, is Type 3 Code 4 - Fragmentation Needed but the Don't Fragment Bit was set 



IB 



31 



Typo 


CO* 


cnedciuni 


Unused 


Link MTU • 


■jp hem** * 64 bits of ortplnal data of the datagram 



4 bytes 



Figure 18: ICMP Fragmentation Needed but the Don't Fragment Bit was set Message Format 

The Unused field will be 16 bits in length, Instead of 32 bits, with this type of message. The rest of 
the 16 bits will be used to carry the MTU used for the link that could not deliver the datagram to 
the next hop (or destination) because the size of the datagram wa3 too big to cany. Since this 
datagram could not be fragmented (the DF Bit was set) an error message has been sent to the 
sender indicating that a lower MTU should be used, hinting the size of the next hops links. 

A.1.1.2 Source Quench (Type 4) 

ICMP Source Quench message type Issued by a Router: 

If a router sends this message, It means that the router does not have the buffer space needed to 
queue the datagrams for output to the next network on the route to the destination network, 

RFC 1812 specify that a router should not generate Source QuBnch messages, but a router that 
does originate Source Quench message must be able to limit the rate at which they are 
generated (because it consumes bandwidth and it is an ineffective antidote to congestion). 



A router receiving an ICMP Source Quench message type: 
When a router receives such a message it may Ignore it 



ICMP Source Quench messago type Issued by a Host: 

If a destination host sends this message (it may be implemented), it means that the datagrams 
arrive too fast to be processed. The ICMP source quench message is a request to the host to cut 
back the rate, which It is sending traffic to the Internet destination. 
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The ICMP header code would be always zero. 



Host receiving an ICMP Source Quench message typo: 

An ICMP Source Quench message must be reported to the transport layer, UDP or TCP, the host 
should throttle Itself back for a period of time, than gradually Increase the transmission rate again. 

A. 1.1, 3 Redirect (Type 5) 

ICMP Redirect message type Issued by a Router: 

If a router generates this message, it means the host should send future datagrams for the 
network to the router who's IP Is given In the ICMP message. The router should be always on the 
same subnet as the. host who sent the datagram and the router that generated the ICMP redirect 
message. 

A routing loop Is generated when the router IP address matches the source IP address in the 
original datagram header. 

Routers must not generate a Redirect Message unless all the following conditions are met 

o The packet Is being forwarded out the same physical interface that 
it was received from, 

o The IP source address In the packet is on the same Logical IP 
(Suh) network as the next-hop IP address, and 

o The packet does not contain en IP source route option. 



at 



Typo 


Crto 


Qifittftunt 




Router IP adiiftiOT 






IP hAftrfep + 64 bto Of original <tota oT tin* dAtflflram 


r 



4byte* 
4 byte* 



Figure 19: ICMP Redirect Message Format 



A router receiving an ICMP Redirect message type; 

A router may Ignore ICMP Redirects when choosing a path for a packet originated by the router if 
the router is running a routing protocol or If forwarding is enabled on the router and on the 
interface over which the packet is being sent* 

Four different codes can appear In the code field: 



Code 


Meaning 


0 
1 


Redirect Datagram for the Network (or subnet) 
Redirect Datagram for the Host 



129 

Copyright © Oflr Arkin, 2000-2001 



PAGE 183/209 * RCVD AT 7/1/2004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DNIS:7469694 * CSID:9497609502 * DURATION (mm-ss):57-46 



Jun-30-2004 09:51pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-702 P 080/1 05 F-G10 



o 




1CMP In Scanning 

VemtonZS 



Code 



Meaning . 




2 



3 



Redirect Datagram for the Type of Service and Network 
Redirect Datagram for the Type of Service and Host 



Table 13: Redirect Codes 



1CMP Redirect message type Issued by a Host; 

A host should not send an ICMP Redirect message/Redirects are to be sent only by routers. 



Host receiving an ICMP Redirect message type: 

A host receiving a Redirect message must update Its routing Information accordingly. Every host 
must be prepared to accept both Host and Network Redirects. 

The Redirect message should be stfently discarded with the following cases: 

o The new gateway address it specifies Is not on the same connected (sub-) net through 

which the Redirect arrived, 
o If the source of the Redirect is not the current first-hop gateway for the specified 

destination. 



A.1.1,4 Time Exceeded (Type 11) 

ICMP Time Exceeded message type Issued by a Router. 

If a muter discovers that the TimeTo-Uve field In an IP header of a datagram he process equals 
zero hB will discard the datagram and generate an ICMP Time Exceeded Code 0 - transit TTL 
expired (this can also be an Indicator of a routing loop problem). 

When the router reassemble a packet that Is destined for the router, ft Es acting as an Internet 
host Host rules apply also when the router mcefves a Time Exceeded message. 

A router must generate an ICMP Time Exceeded message code 0 when It discards a packet due 
to an expired TTL field. A router may have a per-lnterface option to disable origination of these 
messages on that Interface, but tiiat option must default to allowing the messages to be 



ICMP Time Exceeded message type issued by a Host: , - 

If a host cannot reassemble a fragmented datagram due to missing fragments within its time limit 
it will discard the datagram and generate an ICMP Time Exceeded Code 1- reassembly TTL 



A.1.1.5 Parameter Problem (Type 12) 

ICMP Parameter Problem message Is sent when a router {must generate this message) or a host 
{should generate this message) process a datagram and finds a problem with the IP header 
parameters. It Is only sent If the error caused the datagram to be discarded. 

The Parameter Problem message Es generated usually for any error not specifically covered by 
another ICMP message. 



. originated. 



Exceeded. 
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IF code 0 is used, the pointer field will point to the exact byte In the original IP Header, which 
caused the problem. 

Three different codes can appear In the code field: 



Codes ; 


Meaning 


0. 


Pointer Indicates the error (unspecified error) 


1 


Missing a Required Option 


2 


Bad Length 


Table 20: Parameter Problem Codes 



Receipt of a parameter problem message generally indicates some local or remote 
Implementation error. 



at 



Typa 


Coda 


Checteum 


PflWar 




Unused 




IPhAader-»-64bfaorod£*nal dais of the datagram 



4bytoa 
4 byte* 



Figure 20; ICMP Parameter Problem Message Format 
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Appendix B: ICMP "Fragmentation Needed but the Don't Fragment Bit was 
set" and the Path MTU Discovery Process 57 

When one host needs to send data to another host, the data is transmitted In a series of IP 
datagrams. We wish the datagrams be the largest size possible that does not require 
fragmentation 58 along the path from the source host to the destination host 

Fragmentation by the IP layer raises few problems; 

o If one fragment from a packet is dropped, we need to retransmit the whole 
packet. 

o Load on the routers, which needs to do the fragmentation, 
o Some simpler firewalls would block ad fragments because they do not contain the 
header Information for a higher layer protocol needed for filtering. 

The Maximum Transfer Unit (MTU) Is a link layer restriction on the maximum number of bytes of 
data in a single transmission. The smaHest MTU of any link on the current path between two 
hosts Is called the Path MTU. 



B.1 The PATH MTU Discovery Process 

We use the Don r t Fragment Bit Flag in the IP header to dynamically discover the Path MTU of a 
given route; The source host assumes that the PMTU of a path Is the known MTU of its first hop. 
He will send all datagrams with that size, and set the Don't Fragment Bit If along the path to the 
destination host, there is a router that needs to fragment the datagram In order to pass it to the 
next hop, an ICMP error message (Type 3 Code 4 "Fragmentation Needed and DF set") will be 
generated, since the Don't Fragment bit was set. When the sending host receives the ICMP error 
message he should reduce his assumed PMTU for the path. 

The process can end when the estimated PMTU is low enough for the datagrams not to be 
fragmented. The source host itself can stop the process if he is willing to have the datagrams 
fragmented in some circumstances. 

Usually the OF bit would be set in all datagrams, so if a route changes to the destination host, 
and the PMTU is lowered, than we would discover it 

The PMTU of a path might be Increased over time, again because of a change In the routing 
topology. To detect it, a host should periodically Increase its assumed PMTU for that link. 

The link MTU field in the ICMP "Fragmentation Needed and DF set" error message, carries the 
MTU of the constricting hop, enabling the source host to know the exact value he needs to set the 
PMTU for that path to allow the voyage of the datagrams beyond that point (router) without 
fragmentation. 

B*2 Host specification 

A host must reduce his estimated PMTU for the relevant path when he receives the ICMP 
"Fragmentation Needed and the DF bit was set" error message. RFC 1191 does not outline a 
specific behavior that is expected from the sending host, because different applications may have 
different requirements, and different implementation architectures may favor different strategies. 



37 RFC 1 191, http://wwwJetf nm/rfc/rfc1 1 61 .bet. J, Mogul, 5. Doaring, 

88 When we send a packet that Lite too large to be sent across a link as a single unft. a router needs to slice/spilt the 
packet into smaller parts, which contain enough information for the receiver to reassemble them. This te called 
fragmentation. 
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The only required behavior is that a host must attempt to avoid sending more messages with the 
same PMTU value In the near future. A host can either cease setting the Don't Fragment bit In the 
IP header (and allow fragmentation by the routers In the way) or reduce the datagram size. The 
better strategy would be to lower the message size because fragmentation will cause more traffic 
and consume more Internet resources, 

A host using the PMTU Discovery process must detect decreases in Path MTU as fast as 
possible. A host may detect Increases in Path MTU, by sending datagrams larger than the current 
estimated PMTU. which will usually be rejected by some router on the path to a destination since 
the PMTU usually will not increase. Since this would generate traffic back to the host, the check 
for the Increases must be done at infrequent intervals. The RFC specify that an attempt for 
detecting an Increasment must not be done less than 10 minutes after a datagram Too Big has 
been received for the given destination, or less than 2 minute after a previously successful 
attempt to increase. 

ThB sending host must know how to handle an ICMP "Fragmentation Needed and the DF bit was 
sef error message that was sent by a device who does not know how to handle the PMTU 
protocol and does not include the next-hop MTU in the error message. Several strategies are 
available: 

* The PMTU should be set to the minimum between the currently assumed PMTU and 
S76 w . The DF bit should not be set in future datagrams tor that path. 

• Searching for the accurate value for the PMTU for a path. We keep sending datagrams 
with the DF bit set with lowered PMTU until we do not receive errors. 



A host must not reduce the estimation of a Path MTU value below 68 bytes. . 

A host MUST not increase Its estimate of the Path MTU In response to the contents of a 
, Datagram Too Big message. 



B.3 Router Specification 

When a router cannot forward a datagram because it exceeded the MTU of the next-hop network 
and the Dorvl Fragment bit was set, he is required to generate an ICMP Destination Unreachable 
message to the source of the datagram*, with the appropriate code Indicating "Fragmentation 
needed and the Don't Fragment Bit was sef. In the error message the router must include the 
MTU of the next-hop In a 16blt field inside the error message. 



o B 16 31 



| TyfH~3 


Co* =4 


. cumm 


unused (zero) 


lhcmtU 


jPbwdBT+GiUB rf ofeFdcttacf thodatigam 



Figure 21: ICMP Fragmentation Required with Link MTU 



59 The usage of the lesser between 676 and the first-hop MTU as the PMTU for a declination, whteb Is not connected to 
the same network was the old implementation. The results were the use of smaller datagrams man necessary, waste of 
Internet resources, and not being optimal. 
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The value of the next-hop MTU field should be set to the size In bytes of the largest datagram that 
could be forwarded, along the path of the original datagram, without being fragmented by this 
router. The ©fee Includes IP header plus IP data and no lower level headers should be Included. 

Because every router should be able to forward a datagram of 68 bytes without fragmenting it, 
the link MTU field should not contain a value less than 68. 

B,4 The TCP MSS (Maximum Segment Size) Option and PATH MTU Discovery 
Process 

The RFC specify that a host that is doing Path MTU Discovery must not send datagrams larger 
than 576 bytes unless the receiving host grants him permission. 

When we are establishing a TCP connection both sides announce the maximum amount of data 
In one packet that should be sent by the remote system - The maximum segment size, MSS (If 
one of the ends does not specify an MSS, It defaults to 53B - there Is no permission from the 
other end to send more than this amount). The packet generated would be. normally, 40 bytes 
larger than the MSS; 20 bytes for the IP header and 20 bytes for the TCP header. Most systems 
announce an MSS that Is determined from the MTU on the interface that the traffic to the remote 
system passes out from the system through. 

Each side upon receiving the MSS of the other side should not send any segments larger man 
the MSS received, regardless of the PMTU. After receiving the MSS value the Path MTU 
Discovery process will start to take affect We will send our IP packets with the DF bit set allowing 
us to recognize points in the path to our destination that cannot process packets larger as the 
MSS of the destination host plus 40 bytes. When such an ICMP. error message arrives, we should 
lower the'PMTU to a path (according to the link MTU field, or If not used, to use the rules 
regarding the old Implementation) and retransmit The value of the link MTU cannot be higher 
than the MSS of the destination host When retransmission occurs resulting from ICMP type 3 
code 4 error message, the congestion windows should not change, but slow start Should be 
Initiated. The process continues until we adjust the correct PMTU of a path (not receiving ICMP 
error messages from the intermediate routers) which will allow us to fragment at the TCP layer 
which is much more efficient than at the IP layer. 
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Appendix C: Mapping Operating Systems for answering/discarding ICMP 
query message types 

















... 

Operating Systom 


Info; 


Time stamp 


Address MasK 


AUaress Onaa*t- 


ipttL on 


IP | IL OH' 


■Request 


. Request 


Bequest 


Raquest Frag. 




ICMP 










datagrams- 


datagrams 






■ i * 




• • 


. ._ 1i\ Cj a nl\j - 


In Rot 


Debian GNU/ LINUX j 




+ 


— : — r~ 




255 


64 


£2, Kernel 2.4 test 2 (") 










255 


54 


Redhat LINUX $2 










Kernel 2.2.14 O 










64 


54 


LINUX Kernel 2.0 x 










Fr«eBSD4.on 


- 




- 


- 


255 


255 


Free BSD 3.4 


- 


+ 






255 


255 


OpenBSD 2.7 




+ 






255 


255 


OpenBSO 2.6 






- 


- 


255 


255 


NatBSD • 










255 




BQDI BSD/OS 4.0 




+ 


- 


- 


255 




BSPI 33D/OS 3.1 




+ 






265 




Solaris 2.5.1 


- 


+ 




* (0,0.0.0) 


265 


255 


Solaris 2.6 


- 




*- 


+• jo.o.o.o) 


255 


255 


Solaris 2.7 O 






+ 


* (0.0.0.0) 




255 


Solaris 2.8 




+ 




+ (0.0.0.0) 


255 


255 


HP-UX V10.20 






- 




255 


255 


HP-UX v1 1.0 








+ (0.0.0.0) 


— ire 




Compaq Tru64v5.0 (*) 


+ 


+ 


*• 




64 




Wx 6.5.3 O 


■ 


+ 


■ 




abb 




Irix 6.5.5 (') 




+ 




■ 


255 




AIX4.1 C) 


+ 


+ 


■ 




255 




A IS/ 4 A /+ *k 

AIX 3.2 (*) 




+ 


** 


m 


/DO 




ULTRIX4.2-4.5 H 




+ 


+ 


+ 










+ 






255 




NoveH Netware 5.1 SP1 










128 




n 










128 




Novel Netware 5,0 (") 












Novell Netware 3.12 










128 




Windows 95 






i- 


+ 


32 


32 


Windows 98 (•) 








+ 


128 


32 


Windows SB SE O 






+ ; 


+ 


128 


32 


Windows ME(") 




+ 






128 


32 


Windows NT 4 WRKS 








+ 


128 


32 


SP3f) 














Windows NT 4 WRKS 










128 


32 


SP6af) 














Windows NT 4 Server 










128 


32 


SP4 












128 


Windows 2000 










128 


Professional (*) 










128 


128 


Windows 2000 Server 




+ 






. H 
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Natwoifclng - 
Device^. 


. "info; " . 
' Request 


Time Stamp ' 
Request ; 


"Addres9'Me$k ■: 
Request 

" • ■. ..> 'J 


Addres3 Mask 
Request fVafl.' 


JPTTLon , 
j datagrams 
-to Reply- 


IP TTL on. 

t - ICMP.,. 
dats^rarns 

! - In Req^ 


Cisco Catalyst 
5505 with OSS 
v4.5 


+ 








60 


60 


Cisco Catalyst 
2900XLwflh IOS 
11* 


+ 


+ 






255 




Cisco 3600 with 
10511^ 










255 




Cisco 7200 with 
IOS 11.3 


+ 








255 


255 


Intel Express 8100 
ISDN Router n - 






+ 


+ .- 


64 
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Appendix D: ICMP Query Message Types with Code field !-0 



Operating System : : 


Info. Request . 


Time Stamp-Request.. 


AdoV^ssMask 
,| Request ■ 




■ECHO 
Request 




DaWan GNU/ UNUX 2.2. 
Kernel 2.4 tetf 2 f) 
RedhatUNUX 6.2 Kernel 
2.2.14 (-) 

Fl»eBSD4.0 O 
FreeBSD 3.4 
OpenBSD 2.7 
OpenB$D 2.6 
Nel&SD 

BSDI BSD/OS 4.0 H 
BSDI BSD/OS 3.1 

Solaris 2.5.1 
5oM&2.S 
Solaris 2.7 £*) 
Solans 2.& 

HP-UX vl 0.20 
HP-UX vt 1,0 

Comp^ Tm64v5.0(*) 

Irtx 6.5.3 O 
Mx 6.5.8 O 

A1X4.1 O 

ULTOIX4.2-4.S O 

OponVMS V7.1-2 O 

Novell Netware 5.1 SP1 (■) 
Novell Netware 5.0 O 
Movetl Netware 3.12 O 

Windows 95 
Windows 9Q H 
Windows 90 SEO 
Windows MED 
Window* NT 4 WRKS SP 3 

o 

Windows NT 4 WRKS SPBa 

n 

Windows NT 4 Server SP4 
Windows 2000 Professional 

n 

Windows 2000 SeTVerH 


w 

* 
* 

+ (1=0) 

*[!«0) 

+ 0=0) 
+ (1=0) 

+ (1=0) 
+ (1-0) 

V 

: 


+ (0) 
+ (0) 

+ (1=0) 
+ 0=o) 
+ 0-0) 

+ (1=0) 
+ (1=0) 
+ 0-=0) 
+ (1=0) 

+ (1=0) 

+ (1=0) 

. + (NO) 
+ (1=0) 

+ (1=0) 

+ 0=o) 

+ 0-0) 
+ 0=0) 

+ (l=0) 

+ 0=0) 

+ (1-0) 

+ (1=0) 

- (CHANGE) 

- (CHANGE) 
-(CHANGE) 

-(CHANGE) 
-(CHANGE) 


+ (l=0) 
+ 0»*0) 
+ 0=0) 
+ (M>) 

+ 0=0) 

+ 0-0) 
+ (I»0) 

+ 
+ 




+ (1=0) 
+ P=0) 

+ (!=0) 
+ (1=0) 

+ 0=0) 

+ (1=0) 
+ (1=0) 

+ 0=0) 
+0=0) 

+ (l»0) 
+ 0=°) 

+a-o) 

+ (!=0) 
+ (1=0) 

+ 0=o) 

+ (t=0) 

+ 0=o) - 

+ 0=0) 

+ (i-b) 

+ 0=0) 
+ 0=0) 

+ (1=0) 
+ (0) 

! +(0) 

+ (0) 
+ {0) 

+ C0) 

+ (0) 

+ (0) 
+ (0) 

+ (0). 
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Netvraifc^g Devices 


info. Request 


Tlmo'Slamp Request 


Address Mask - 
\Request- \ 




ECHO 
Request 




Cisco Catalyst 5505 with 
OSS v4.S 

Cisco Catalyst 2900XL with 
IOS 11.2 


! + 


+ 
+ 


+ 




+ (!0) 
+ (10) 




Cisco 3BOO with fOS 1 1_2 










+ (!0) 
+ (!0) 




CteCo 7200 w&h IOS 11.3 




+ 








Intel Express 8100 ISDN 
Router f) 
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Appendix E: ICMP Query Message Types aimed at a Broadcast Address 



.Operating System : 



Debian GNU/ LINUX 2J2, 
Kemol 2.4 test 2 
Redhat LINUX 6^ Kernel 
2^.14 0 

FreeSSD 4.0 f) 
FraeBSD 3.4 
Open BSD 2.7 
OpenBSDze 
NetBSD 

BSDI DSD/OS 4,0 C) 
BSDI BSD/OS 3.1 f) 

SotarisZ5,1 
Solaris 2.6 
Solaris 2.7 
Solaris 2.0 

HP-UX v1 0,20 

Compaq Tru64 v&p (") 

iffxB.5^n 

AIX4.1 O 
ATX3.2C) 

ULTRlX«-4^(*) 

OpenVMSy7.1-2(*) 

Novel Netware 5.1 SP1 {*) 
Novell Netware 5.0 (■) 
Novell Netware 3.12 (*) 

Windows 95 
Windows 93 
Windows easEO 
Windows Men 
Windows NT 4 WRKS SP 
30 

Windows NT 4 WRKS SP 
6aC) 

windows NT 4 Server SP4 

Windows 2000 
Professional (*) 
Windows 2000 Server C) 



Inf^Request 



Broadcast 



Time Stamp Request 
Broadcast 



+ 
+ 

+ 



Address Mask 
: F*fcfuest, 

\ Broadcast 



Echo Request 
Broadcast 



130 

Copyright © Oflr Arktn, 2000-2001 
bitp^/www.evB^seciJrfty.cnm 



PAGE 1 93J209 * RCVD AT 71112004 12:03:40 PM (Eastern Daylight Time] * SVR:USPT0€ FXRF-2/2 * DNIS:7469694 * CSID:9497609502 * DURATION (mm-ss):57-46 



Jun-30-2004 09:53pm Frcm-KNQBBE MARTENS OLSON BEAR 

o 



949 7609502 



T-702 P. 090/105 . F-610 



ICMP Usage In Scanning 
Version 2.S 



Networking Devices 

' ■ " - : ' ! :,■ 


Info* Request 


• Time Stamp * 
Y" # Request * 


• Address Mask 
.! Request. • 




Echo 




\±- " : . ': ' 


Broadcast 


. Broadcast; 


Broadcast - 




Broadcast 




Cisco Cafcry st 5505 
vtfth OSS V4.5 
Cisco Catalyst 29Q0XL 
with IOSn.2 


+ • 


+ 


«* 




+ 




Cisco 3600 with JOS 
11.2 

Cisco 7200 With IOS 
11.3 










+ 




Intel Express 8100 
ISDN Router n 












Big Question 
Marks 



140 



Copyright © OflrArWn, 2000-2001 

h«p://www l8 vs-securitv.cGm 



PAGE 1 94/209 * RCVD AT 7/1/2004 12:03:40 PM lEastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DN1S:7469694 * CSID:9497609502 * DURATION (mm-ss):5746 



Jun-30-2004 09:53pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-702 P. 091/105 F-610 




ICMP Usage In Scanning 
Version 2.5 



Appendix F: Precedence Bits Echoing with ICMP Query Request & Reply 





Opdraflng Systflm .\ , 


Information . 
Request 
^WHh! r 
precedenc«=0 


' Time Stamp " 
- Request . 
. With Precedence!^ 


Address Mask 
• Request 
. With Precedence!^ 


Echo Request 
With Precedence^ 






ueoian vSNl// LINUX 2.2, 
Kernels test 2 
Rfitfhal LINUX 6JZ Kernel 
Z2A4 


Not Answering 
Not Answering 


1 1=0x00 
f I— o*on 


Not Answering 
Not Answering 


r=oxoo 

1=0x00 






FreeBSD4.0 
FreeBSD 4.1.1 
OpenBSD 2.7 

opontl5D 2.6 
NctBSD 

BSDI BSD/OS 4.0 
ESDI BSD/OS 3.1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1-0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
• Not Answerinn 
Not Answering 
Not Answering 


1=0x00 

I^QvOn 
1=0x00 

1=0x00 
i-UXW 






Solaris 2.5.1 
Solans 2,6 
Solaris Z7 
Solaris 2.8 


Not Implemented 
Not Implemented 
Not Implemented 
Not Implemented 


1=0x00 
!=Qx00 
1=0x00 


!=0x00 
1=0x00 
1=0x00 


r«»oxoo 

1=0x00 
1=0x50 






HP.UXv10.2D 

UD 1 IV w4 4 ft 


Not Answering 


Not Answering 


Not Answering 
1=0x00 ->, 0x00 


1-0x00 -*QxOO 






Compaq Tru64 v5.0 . 


1=0x00 


1=0x00 


Not Answering 


1=0X00 






AIX 4.3 
ADC.42.1 
AIX 4.1 
AIX 3.2 


1=0x00 

1=0x00 
1-0x00 


1=0x00 
1=0x00 
1^=0x00 
1=0x00 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 
!=0x00 
1=0x00 
1=0x00 






ULTRIX 0-4,5 


0X00 


0x00 


0X00 


0x00 






QpenVMS v7.1-2 


OxOO 


0x00 


0x00 


1=0x00 






Windows 95 
Windows 98 
Windows 93 SE 
Windows ME 

Wfotfows NT 4 WRK3 SP3 
Windows NT 4 WRKS Sp 
6a 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 . 

0x00 
Not Answering 
Not Answering 


0x00 
Not Answering 

Not Answering 


1=0x00 
1=0x00 
1=0x00 
1=0X00 
1-0x00 






Windows NT 4 Server SP4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
0x00 
0x00 


Not Answering 
Not Answering 
Mot Answering 


1=0x00 
0X00 

OxOO I 



141 

Copyright © Ofir Arkrn, 2000*2001 
hHp://ww W .svs-ft^M^ y gnm 



PAGE 195/209* RCVD AT 7/112004 12:03:40 PM [Eastern Daylight Time]* SVR:USPTO-EFXRF-2/2 * DNIS:7469694 * CSID:9497609502 * DURATION (mm-ss):5746 



Jun-30-2004 09:54pm FronrKNOBBE MARTENS OLSON BEAR 949 7609502 T-702 P. 092/105 F-610 

o - '* ' o 

ICMP Usage in Scanning 
Version Z 5 



Appendix G: IC MP Query Message Types with TOS! ^ 0 



Operating System 


Information 
Request ! 

With TnOI^/VwflA 


Time Stamp Request 
WlthTOS!=0x00 


Address Mask 

Request 
WithTOSI^OxOO 


•• Echo Request 
, ;WlthT0Sl=Qx00 


Deblan GNU/ LINUX 2_2, 
Kernel 2 4 test 2 ( % \ 
Redhat LINUX 6.2 Kernel 


Not Answering 
Not Answering 


1-0x00 
1=0*00 


Not Answering 
Not Answering 


1=0x00 
1=0x00 


freeBSD 4.0 f) 

OpenBSD2.7r) 
OpenBSD 2.6 

BSD1 BSD/OS 4.0 H 

Ptcm ocn/nc o * i>\ 
QflMJ t»U/Uo J.l { J 


Not Answering 
Not Answering 
' Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


1=0x00 

1=0x00 
JHJxOO 
1^0X00 
1=0x00 
1=0x00 


NotAnsweimg 
Not Answering 
Not Answering 
Not Answering 
Net Answering 
Not Answering 
Not Answering 


1=0x00 

• 1=0X00 
1=0x00 
1"0X00 
1=0x00 


Solaris 2.6 
Solaris 2.7 (■) 
Solaris 2.5 O 


Not Implemented 
Not Implemented 
Not Implemented 
Not Implemented 


[-0x00 
1=0x00 


1=0x00 
1=0x00 


IKU00 
1=0x00 


HP-UX vlO.20 
HP-UX rM.O 


Not Answering 


Not Answering 


Not Answering 
1=0x00 


!»OxTJ0 


Compaq Tru64 v5,0 (*) 




1-0x00 


Not Answering 


1=0x00 


IrixBSao 

irix6.5.a n 


Not Answering 
Not Answering 


MfcCO 
1=0x00 


Not Answering 
Not Answering 


1=0X00 
1=0x00 


AIX4.1 (*) 
AJX3.2H 




!=0xO0 
1-0x00 


Not Answering 
Not Answering 


1*0x00 
1=0x00 


ULTRJX4.2-4.5r) 




0x00 


0x00 


0x00 


Open VMS vM^2 (") 




1=0x00 


VCWQO 


1=0x00 


Novell Netware S.1 SP1 (•) 
Novell Netware 5.0 (*) 
Novell Netware 3.12 n 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


0x00 
0x00 
0x00 


Windows 95 
Windows 98 (*) 
Windows 08 SE <*) 
Windows ME f) 
Windows NT 4 WRKS SP 3 

P 


Not Answering 
Noi Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

0x00 
• 0x00 
Oxoo 
Not Answering 


0x00 
Not Answering 


1=0x00 
1=0x00 
1=0x00 
1=0x00 


Windows NT 4 WRKS SP 6a 

o 


Not Answering 


Not Answering 


Not Answering 


r=oxoo 


Windows NT 4 Server SP4 
Windows 2000 Professional 

o 


Not Answering 
Not Answering 


Not Answering 
0x00 


Not Answering 
Not Answering 


1=0X00 
0x00 


Windows 2000 Server ff 


Not Answering 


0x00 


Not Answering j 


0x00 
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Appendix H: Echoing the TOS Byte Unused bit 



Operating .System 

" ■ ... ... 


Information : ; 
'. " Request 
Wtoi Unuseflvr. 


.Time Stamp- Request 
• WIth : Unused=1. . 


Address Mask 
. .. Request. 
; With UrtusecM 


Erhn RnrtiiflRt 

WKhUnu&ed=1 


Debfan GNU/ LINUX 2J2, 
Kernel 2.4 tost 2 
RedhatUNUX gjz Kernel 
2.2.14 


Nol Answering 
Not Answering 


0x1 
0x1 


Not Answering 
Not Answering 


0x1 
0x1 


Free BSD 4 0 
FreeQSD 4.1.1 
Open&SD 2.7 
Open&SD 2,6 
NetBSD 

BSDI BSD/OS 4.0 
BSD! BSD/OS 3,1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answer^ 
Not Answering 


0x1 
0x1 


Not Answering 

Not Answering 
Not Answering 
Not Answering 

flint A nPI IIArin>i 

rnJi /viBwenng 
Not Answering 


0x1 

UX 1 


Sobfjs 2.5.1 
Solans 2.6 
Solaris 2.7 


Not Implemented 
Not Implemented 
Not Implemented 
Not Implemented 


0x1 
0x1 
0x1 


0x1 
0x1 
0x1 


0x1 
0x1 

0x1 | 


HP-UX v1 0.20 
HP-UX v1 1.0 


Mot Answering 


Not Answering 


Not Answering 
0x1 


0x1 


Compaq Tru64 v5.0 


0x1 


0x1 


Not Answering 


0x1 


AIX4.3 
AIX 4.2.1 
AIX4.1 , 
AIX3.2 


£5 S E 


0x1 
0x1 
0x1 
0x1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
0x1 
0x1 
0x1 


m.TRIX4i-4.S 


0x0 


0x0 


0x0 


0x0 


OpenVMS v7.V2 


0x1 


0X1 


0x1 


Oxi 


Windows 95 

window* ee 

Windows 98 3£ 
Windows M£ 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SP4 
Windows 2000 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering | 


Not Answering 
0x0 
0*0 
0x0 

Not Answering 
Not Answering 
Not Answering 

0x0 

0x0 


0x0 
0x0 
Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


0x1 
0x1 
0x1 

Qx1 

0x0 
0x0 



143 

Copyright © Ofir Arkln, 200 0-2001 

hHp://www.svs-sficurity.eom 



PAGE 1 97/209 ' RCVD AT 71112004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DHIS:7469694 " CSID:9497609502 * DURATION (mm-ss):5746 



Jun-30-2004 09:54pm Frcm-KNOBBE MARTENS OLSON BEAR 949 7609502 T-702 P 094/105 F-610 

o . . o 

(CMP Usage fn Scanning 
Versions 



Appendix I: Using the Unused Bit 



Operating System : | * : • : V * 


■ Info. Re'gqest: 


.Time Stamp r 
Request ' 


Address Mask 
* Request 


Echo Request 


Deb ton GNU/ LINUX 9 2 Knmal 

2^test2 


Noi Answering 




Not Answering 




Redhat UNUX 6.2 Kernel 2.2.14 


Not Answering 


_ 


Not Answering . 




FreeBSD4.0 
FreeBSD 3.4 

OponBSD 2.6 
NetBSD 

BSD} BSD/OS 4.0 
BSDI BSD/OS 3.1 


Not Answering 
. Not Answering . 
Not Answering 
Not Answering 
Mot Answartno 
Not Answering 
Not Answering 


m 

m 


Not Answering 
Not Answering 
Not Answering 
Not answering 
Not Answering 
Not Answering 
Not Answering 


- 

— 

- 


Solaris 2.5,1 
Solaris 2.6 
Solaris 2.7 
. Solaris 2,$ 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ 
+ 

-t- 
+ 


+ 


+ 
+ 


HP-UX \* 0.20 
HP-UXV11.0 


Not Answering 


Not Answering 


Not Answering 
+ 


4- 


Compaq Tru64 v5.0 






Not Answering 




Mx 6.5.3 
lrtX6.5.B 


Not Answering 
Not Answering 




Not Answering 
Not Answering 




AIX 4.t 
AIX3.2 






Not Answering 
Not Answering 




ULTRJX4.2-4.5 










OpenVMS v7.1-2 ' 










Novell Netware 5.1 5P1 
Novell Netware 5,0 
Novell Netware 3.12 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 




Windows OS 
Windows 98 
Windows 9a S£ 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SP4 
Windows 2QD0 Professional 
Windows 2000 Server 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

Not Answering . 
Not Answering 
Not Answering 


*• 

Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 
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ICMP Usage In Scanning 
VerelonZ5 



Appendix J: DF Bit Echoing 



Opera^gSy^tefh, - . : * 


Into Request 


Tlrne Stamp/ 
Request 


Address Masjc 
.Request 


Echo Request 


DeWan "GNU/ UNUX 2.2, Kernel 
24test2r) 


Not Answering 


+(-DF) 


Not AnswRrtna 


+ f . OP 1 

I ur J 


Rorihat LINUX 6.2 Kernel 2^.14 (*) 


Not Answering 


+(-DF) 


Not Answering 


f(-DF) 


FreeBSD 4.0 f) 
FreeBSD 3.4 
OpenBSD 2.7 
OpenBSD 2.6 
NetBSD 

BSDI BSD/QS 4.0 
BSDI BSD/OS 3.1 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Nat Answering 
Not Answsrina 


+ ( + DF) 
+(+DF) 
+ ( + DF ) 
+ ( + DF) 
•*■ ( + DF ) 
+ (+DF) 


Not Answering 
Not Answering 

NAf AnnuunHrwi 

iiyji rvjiawoiiiiy 

Not Answering 
Not Answering 

hint AiMHiiailnM 

»Hot Answering 


*■(-* DF) 
+ (+DF) 

+ ( + DF) 
•*-r 4. nit t 

+ C + DF) 
+ ( + DF ) 


Solaris 2.5.1 
Solaris 2.6 
Solaris 2.7 H 
Solaris 2-9 


Not Answering 
Not Answering 
Not Answering 
Not Answering 


+(*DF) 
+ (+DF) 
. + C + DF) 


+ ( + DF) 
+ {+DF) 


+ ( + DF) 
+ (+DF) 
+ (*DF.) 


HP-UX V10.20 
HP-UX v1 1.0 


Not Answering 


Not Answering 


Not Answering 
+ ( + DF ) 


+ ( + DF) 


Compaq Tru64v5.0{*) 




+ ( + DF) 


Not Answering - 


M+DF) 


Irfx 6.5.3 (■} 
Irtx 6.5.fl{-) 


Not Answering 
Not Answering 


t( + DF) 
+ (+DF) 


Not Answering 
Not Answering 


+ < + DF) 
+ (+DF) 


AIX4.1 O 

ADC 3-2 O 




+ ( + DF) 


Not Answering 


+ / + pip \ 
+ ( + DF) 


ULTRIX4.2-4.5H 




+ {-DF) 




+ <-DF) 


OpenVMS v7.1-3f) 




+ ( + DF ) ' 


•*( + DF) 


+ (+DF) 


Novell Netware 5.1 SP1 (•) 
Novell Netware 5.0 <*) 
NoveJI Nolware 3.12 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering 
Not Answering 


Not Answering 
Not Answering i 
Not Answering 


+<-DF) 
+ (-DF) 
+ (-DF) 


Windows 95 
Windows 9ft C) 
Windows 9BSE n 
Windows ME f) 
Windows NT 4 WRKS SP 3 f) 
Windows NT 4 WRKS SP 6a (*) 
Windows NT 4 Server SP4 
Windows 2000 Professional f ) 
Windows 2000 Server H 


Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 
Not Answering 


Not Answering 

+(-DF) 
. -M-DF) 
+<-DF) 
Not Answering 
Not Answering 
Not Answering 
+(-DF) 
+(-DF> 


+ C-PF) 
+ (-DF) 
Not Answering 

Not Answering 
Not Answering 
Not Answering 
Not Answering 


+ (+DF) I 
+ (+DF) 
+ (+DF) 

+ (+DF) 
+ ( + DF) 
+ ( + DF) 
+ ( + DF> 
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Appendix K: ICMP Error Message Echoing Integrity with ICMP Port 
Unreachable Error Message 



Operating 
System 


DF Bit Set! 

with the 
Reply? 


IP Total. 
Length ; 
_j — « : — 


IP 

Identifteatto 
n 


IPTTL • 
field value 

— — — : 


IP Header 
Checksum : . 


UDP 

Checksum 


LINUX Kflmal 




o3IT)9 


Seme 


Changed 


Changed 


Samo 


2.2.x 








according 


because of new 












to hop 


parameters. 












count 






LINUX Kernel 


No 


Same 


Same 


Changed 


Changed 


Same 










according 


because of new 












to hop 


parameters. 












count. 






FreoBSD 4.0 


No 


Same 


Changed. 


Changed 


Changed 


Changed. 








The first 


according 


because of new 


Now equal to 








two bits 


to hop 


parameters* 


ZEROI 








are flipped 


count - 








• • 


with the 














second 














pair. Gives 














anew 














value. 








FreeBSD4.11 


No 


Seme 


Same 


Changed 


Changed 


Changed. 










according 


because of new 


Now equal to 










to hop 


parameters. 


ZERO! 


BSDI 4.1 


No 


Changed 


Same 


count 
Changed 


Changed. Now 


Same 






(20 bytes 




according 


equals to ZEROI 








more) 




to hop 














count 






Sun Solaris 


Yes 


Same 


Same 


Changed 


Changed 


Same 


2S 








according 


because of new 












to hop 


parameters. 












count 






Sun Solaris 


Yes 


Same 


Same 


Changed 


Changed 


Same 


2.7 








according 


because of new 












to hop 


parameters. 












count 






Sun Solarfs 


Yes 


Same 


Same 


Changed 


Changed 


Samo 


2.8 60 








according 


because of new 












to hop 


parameters. 












count 






HPUX11.0 


No Yes 


Same 


Same 


Changed 


Changed 


Same 










according 


because of new 












to hop 


parameters. 












count 






Compaq 


No 


Same 


Same 


Changed 


Changed 


Changed, 


Tru64- 








according 


because of new 


Now equal to 










to hop 


parameters. 


ZEROI 










count 






DG-UX5.6 


No 


Same 


Same 


Changed 


Changed 


Changed. 










according 


because of new 


Now equal to 










to hop 


parameters. 


ZEROI 



60 The DF Bit Is set 
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count 






AJX4.3fp2, 
4.3.4.2.1 

AIX4.1 


No 
No 


Changed 
(20 bytes 
more) 

Changed 
(20 bytes 
more) 


Same 
Same 


Changed 
according 
to hop 
count 
Changed 
according 
to hop 
count 


Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 


Changed, 
Now equal to 
ZERO! 

Same 


ULTRIX 


No 


Same 


Changed. 
The first 
two bits 
are flipped 
wiin ine 
second 
pair. Gives 
anew 
value. 


Changed 
according 
to hop 
count 


Changed. Now 
equate to ZERO! 


Changed. 
Now equal to 
ZERO! 


Open VMS 


No ' 


Same 


Changed. 
The first 
two bits 
are flipped 
with the 
second 
pair. Gives 
a now 
value. 


Changed 
according 
to hop 
count 


Changed, Now 
equals to ZEROl 


Changed. 
New equal to 
ZEROI 


Microsoft 
Windows 98 
Mlrosoft 
Windows 
98SE 

Microsoft 
Windows ME 

Microsoft 
Windows NT 
4 

Microsoft 
Windows 
2000 Family 


No 
No 
No 
No 


Same 
Same 
Same 
Same 


Same 
Same 
Same 
Same 


Changed, 
according 

LU Hup 

count. 

Changed 

according 

to hop 

count. 

Changed 

according 

to hop 

count 

Changed 

according 

to hop 

count 


Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 

Changed 
because of new 
parameters. 


Same 
Same 
Same * 
Same 
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ICMP Usage En Scanning 
Version^ 

Appendix L: A Snort Rule Base for (more Advanced) Basic ICMP Traffic 

The following generic ICMP basic Snort rub base Es also available for download from: 
hfo://vww < svs^ecurity.^^ ruleg/ICMP basic plus . 

alert icrap any any -> any any (mag: * ICMP Echo Reply"; itype: 0; icode: 

0/) 

alert icrap any any -> any any (meg:°ICMP Echo Reply (Undefined Codei)-; 
itype: 0;) 

alert icrap any any -> any any (m0g : »ICMP Unassignedl (Type 1)"; itype: 
X; icode: 0;) 

alert icrap any any -> any any (msg; "ICMP Unassignedl (Tupe 1) 
(undefined Code)"; itype: 1;) 

alert icrap any any ^> any any (msg: rt lCMP Unasaignedf (Type 2)"; itype: 
• 2; icode: 0;) 

alert icrap any any -> any any (msg: ° ICMP Unas signed J (Type 2)" 
(Undefined Code); itype: 2;) m. 
^ alert' icrap any any -> any .any. (msg: "ICMP Destination Unreachable 
(Network Unreachable) "; itype; 3; icode: 0;)*"' 

alert icrap any any -> any any (msg:"lCMP Destination unreachable (Hoot 
Unreachable) ■ ; itype: 3; icode: 1;) 

alert icrap any any any any (msg; "ICMP Destination Unreachable 
(Protocol Unreachable) 11 ; itype: 3; icode; 2;) 

alert icmp any any -> any any (msg:"XCMP Destination Unreachable (Port 
Unreachable)"- itype: 3; icode: 3;) 

alert icrap any any ->any any (rasg:"ICMP Destination Unreachable 
(Fragmentation Needed and DF bit was set)"; itype s 3; icode: 4;) 
alert icrap any any -> any any (msg:"ICMP Destination unreachable 
(Source Route Failed) 1 *; itype t 3; icode: 5;) 

alert icrap any any -> any any (megs "ICMP Destination Unreachable 
(Destination Network Unknown) 11 ; itype: 3; icode: €;) 
alert icrap any any -> any any (msg: "ICMP Destination Unreachable 
(Destination Host Unknown)"; itype: 3; icode: 7;) 

alert icrap any any -> any any (msg: 'ICMP Destination Unreachable 
.(Source Host Isolated) itype: 3; icode: fl ; ) 

alert icmp any any -> any any (msg: "ICMP Destination Unreachable 
(Communication with Destination Network is' Administratively 
Prohibited) rt ; itype : 3 ; icode : 9 ; ) 

alert icmp any any -> any any (msg;"ICMl> Destination Unreachable 
(Communication with Destination Host is Administratively Prohibited)"; 
itype: 3; icode? 10 ; ) 

alert icrap any any -> any any (msg: "ICMP Destination Unreachable 
(Network Unreachable for Type of Service)"; itype: 3; icode: 11;) 
alert icmp any any -> any any {msg; "ICMP Destination Unreachable (Host 
Unreachable for Type of Service)"; itype: 3; icode: 12;) 
alert icmp any any -> any any (msg: "ICMP Destination Unreachable 
(Communication Administratively Prohibited) "; itype: 3; icode: 13;) 
alert icrap any any -> any any (msg; "ICMP- Destination unreachable (Host 
Precedence Violation) " ; itype: 3; icode: 14;) 

alert icrap any any -> any any (msg: "ICMP Destination Unreachable 
(Precedence Cutoff in effect)*; itype: 3; icode: 15;) 
alert icmp any any -> any any (msg: "ICMP Destination Unreachable 
(Undefined Codel)"; itype: 3 ; ) 

alert icmp any any ~> any any (msg: "ICMP Source Quench"; itype: 4; 
icode ; 0 ; ) 
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ICMP Usage in Scanning 
Version 2.5 



n 1 ^^ 0 "? Wy any _> any ^ B 9-"3:CMP Source Ouencn (Undefined 

Cods!)'*; itype: 4;) 

t 1 ? 1 * ™ y any My any <™S5"IC» Redirect (for Network or 

Subnet) h ; i type : 5 ; icode : 0 ; ) 

alert icmp any any -> any any (msg:"lCMP Redirect (for Host)"; itype- 
5; icode: 1 ; ) 

alert icmp any any -> any any (msg:"ICMP Redirect (for TOS and 
Network)"; itype: 5; icode: 2 f ) 

alert icmp any any -> any any (tnsg:"ICMP Redirect (for TOS and Host)"* 
itype* 5; icode: 3;) 

alert icmp any any ~> any any (mag; "ICMP Redirect (Undefined Code!)"- 
itype: 5; ) 1 7 ' 

alert icmp. any any -> any any (msgz«lCMP Alternate Host Address"; 
itype: 6? icoder 0 ; ) 

alert icmp any any any any (msg:«ICMI> Alternate Host Address 
(Undefined Code!)"; itype: 6 ; ) v . 

alert icmp any any -> any any (megs "ICMP Unassigned! (type 7)"; itype - 

7; icode; 0;) 

alert icmp any any -> any any (msg S "iCMP Unassigned! (Type 7) 
(Undefined Code 1) »; itype: 7;) 

alert icmp any any ~> any any (msg : "ICMP Ecno Reauest"; itype- 8- 
icode: 0;) 

alert icmp any any -> any any (msg:"ICMP Echo Revest (Undefined 

Code!) " ; itype: 8;) 

alert icmp any any -> any any (msg:"ICMP Router Advertisment * ; itype: 
9; icode: 0;) 

alert icmp any any -> any any (mag: "ICMP Router Advert i amen t (Undefined 
Code!)"; itype:9 ;) 

alert icmp any any -> any any (msg:-ICMP Router Selection"; itype:- 10; 
icode: 0;) . J * 

alert icmp any any -> any any (msg:»iCMP Router Selection (Undefined 
CodeU " ; itype: 10;) 

alert icmp any any.-> any any (msg : »iCMP Time-To-Live Exceeded in 
Transit"; itype: 11; icode: 0;) 

alert icmp any any -> any any (rosg:"ICMP Fragment Reassembly Time 
Exceeded"; itype: 11; icode? 1;) 

alert icmp any any -> any any (msg: "ICMP Time Exceeded (Undefined 
code!)"; itype: 11;) 

alert icmp any any -> any any (msgs-iCMP Parameter Problem Code 0 
(unspecified Error) "; itype: 12; icode: 0;) 

alert icmp any any -> any any (mag: "ICMP Parameter Problem Code 1 
(Missing a Requiered Option)"; itype: 12; icode: i;) 

alert icmp any any -> any any <msg:"ICMP Parameter Problem Code 2 (Bad 
length)"; itype: 12; icode: 2;) 

alert icmp any any -> any any (mag: "ICMP Parameter Problem (Undefined 
Code!)"; itype; 12;) 

alert icmp any any -> any any (msg: "ICMP Timestamp Request"; itype: 13; 
. icode ; 0 ,- ) 

alert icrap any any -> any any (msg s »ICMP Timestamp Request (Undefined 
CodeU"; itype: 13;) 

alert icmp any any -> any any (msg:»rCMP Timestamp Reply"; itype: 14; 
XCode : 0 ; ) 

alert icmp any any -> any any (msg;"ICMP Timestamp Reply (Undefined 
Codel)"? itype: 14;) 

alert icmp any any -> any any (msg: "ICMP Information Request*; itype; 
15; icode; 0;) 
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^ r ?^ Cm ? ^ y ^ Y ~* anv (nisg:»ICMP Information Request (Undefined 
uoae i j " ; xtype : 15 ; ) 

alert icmp any any -> any any (m8g : "ICMP Information Reply"; itype: 16; 

S 1 ^^ 0 "? my ^ ^ (""©ar^ICMP Information Reply (Undefined 

Code ! J ; itype : 16 ; ) 

alert icmp any any -> any any (msg ; "iCMF Address Mask Request"; itype - 
17; Icode: 0;) 

alert icmp any any -> any any (mscf: "ICMP Address tfaBk Request 
. (Undefined Code!)"; itype: 17;) 

l^^icode? T% r> ^ rmag:,,TCMP Address Mask Reply"; itype: 

alert icmp any any -> any any (mag t "ICMP Address Mask Reply (Undefined 
Code!)-; itype: IB; ) 

alert icmp any any -> any any (mag:»;tCMP Reserved for Security (Type 
19)"; itype: 19; icode; 0;} * 
alert icmp any any -> any any (msgt"ICMP Reserved for. Security (Type 
19) (Undefined Code!)"; itype: 19;) 

alert icmp any any -> any any (msg:"icMP Traceroute" ; itype; 3 0; icode- 

0;J 

alert icmp any any -> any any (msg^'iCMP Traceroute (Undefined Code ! " - 
itype: 30;) 

alert icmp any any -> any any (msgi'lCMP Datagram Conversion Error" ; 
itype: 31- icode: 0;) 

^i e I C ^ Cm ? *" y My " > ^ .(meg: "ICMP Datagram Conversion Error 
(Undefined Code I )» ; itype: 31;) 

alert icmp any any -> any any (msgi"ICMP Mobile Host Redirect"; itvper 
32; icode: 0;) Itf 
alert icmp any any -> any any (msgr'ICMP Mobile Host Redirect 
(Undefined Code!)"; itype: 32;) 

alert icmp any any any any (msg : "iCMP IPV6 Where -Are- You"; itype - 
33; icode: 0;) * 

alert icTOP any any -> any any (msg:"iCMP IPve where-Are-You (Undefined 
Code i )"; itype: 33;) 

alert icmp any any -> any any (magr»XCMP XPV6 I-Am-Here"; itype: 34; 
' icode : 0 ; ) 9 

alert icmp any any -> any any (msg:"ICM* IPV6 I -Am -Here (Undefined 
Code!"? itype: 34;) 

alert icmp any any -> any any (meg: "ICMP Mobile Registration Request" - 
itype: 35; icode: 0 ; ) . ... 

alert icmp any any -> any a^iy (me'g: "ICMP Mobile Registration Request 
(Undefined Codei"; itype: 35;) 

alert icmp any any -> any any (msg:"ICMP Mobile Registration Reply" - 
itype: 36; icode: 0;) 

alert icmp any any -> any any (mag:"XCMP Mobile Registration Reply 
(undefined Code!)"; itype: 36;) 

alert icmp any any -> any any (msg:"lCMP SKIP"; itype: 39? icode: 0 ; ) 
alert icmp any any -> any any (msg:"iCMP SKIP (Undefined CodeJ"; itype: 
33 ; ) 

alert icmp any any -> any any (meg;"iCMP Pnoturia Code 0 (Reserved) »; 
itype: 40; icode: 0;) 

alert icmp any any any any (mag : "lCMP Pnoturia Code 1 (Unknown 
Security Parameters Index)"; itype? 40; icoda; l;) 
alert icmp any any -> any any (msg:"iCMP Photuris Code 2 (Valid 
Security Parameters, But Authentication Failed)"; itype i 40; icode: 3;) 
alert icmp any any -> any any (msg^ICM* Photuris Code 3 (Valid 
Security Parameters, But Decryption Failed)*; itype: 40; inode: 3 ; ) 
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alert icmp any any -> any any (msgr"ICMP photurie (Undefined Code')"- 
itype; 40;) , " 

alert icmp any any -> any any (msg* "ICMP unknown Type 11 ;) 
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For correcbons/additions/suggestions for this research 
paper, please send email to ofir(g)svs-sen iriiy mm 
Further Information and updates would be posted to 
http://ww w.svs~securitY -rr>m 



Thank you for reading 

Ofir Arkin 

Founder 

The Sys-Security Group 
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Sya-5ectjrlty.com « a web ejte cteolcated to 
computer security research. It fe tho homo <rf the ' 
*ICMP Usage In Scanning* research project 
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Tho Trivial Cisco tP Phones Compromise 

The following paper Bite several covwo vulnerabTnUos wllh Cisco systems 1 SIP-besed IP Phone 
79B0 andlte supporting environment These vulnerabilities lead to complete control of a usee's 
erodenti&fe, the total subversion of a user's settings for flie IP Telephony network, and me aWFlty 
let subvert the entire IP Telophony environment MaUdaua occoss tea user's credentials could 
^"^^HK?*^ '^tratfon Hijackfng-, "Call Tracking;, and other voice related attacks, 1 
TT* vt4nerab»ltfes okfet with any deployment sconario, but this paper deals specifically with tare* 
seato deployments as mcwmjiemtod by Cisco. 

Ft* Details I* PJ}£ format -200kb 
Fun DetaQs in pdp ?tpp*H format 



More Viilperabllitig a wfth PlndteJ xpra&aa SIP-based fP Phones Pinotei 
(nHp;ffvvVT^,PlnaW,cqrn) develops Intelligent Java-based vojoa -over-IP phones end softp hones 
lor eervlcB provldera and enlerpfte«s. 



Navigation 

Advisories 

Conference^ 
News 

Picture 

P"t%heti Papacs. 
Upcoming 



JJnte 

Toola 



1 Projects 

I The ICMP Erofect 

' i 

! VoJE 



Using tho vulnerabilities enumerated within this advisory It is pesslbto to Jeopardize critical 
te^ony InfrootmcUffB based en Plngtel's xpmssa SlP-baaed IP phones and softphonea. 
AdoltiOfiaBy, certain vulnerabMes; allow an attacker to take complete control over an IP phone 
or a soflphone node either directly or by circumventfng other SIP entitles on the network by 
abusing the node's credentials'. 

inmost severe Issue discussed Is the way an attacker can exploit vulnerabilities with 
JJyPJngtel portal mMrov.ninoteicom) to subvert a VoIP infrastructure which Includes IP 
Phonos and/or soft phonos from Plngta!.,, >> 

Ful Details In EEE format -5Q0kb 
Ful Detals in UIMU format 
Moderated VOrsfon In txt format 



Xpjobej 

Xprobe2 fct an active operating system fingerprinting tool with a different approach to operating 
system fingerprinting. XprobeZ rely on fuzzy signature matehfng, proba bHstfc guesses, 
mmtfcle matches simultaneously, and a signature f " 



« 




The toofe release Is accompanied by a white paper explaining our fuzzy approach to operating 
system fingerprinting and the various problems faring other remote active operating system 
flngerprintlng tools available today, which we have tried to remedy. 

The current development code (xp/obe2 0.1 rei) is available from: 
Uttp;flwww mffi^oirltV.cr^archJv^^ 

The White Paper la available (taw 



Xprobe 



Novtaate Sys^ecurity.com: i 
{Choose one: -ftp] 

Go 



leiflg Usage In Scanning 

The ICMP protocol may seem harmless at first glance, but In terms of security ICMP Is one of 
the most controversial protocols with the TCP/IP suite. The risks Involved In Implementing the 
ICMP protocol In a network regarding a canning are the subject or this research. Issues 
dteeussod range from understanding the different ICMP messages, reconnaissance (host 
detection. Inverse maooina. Active and do salve eeerallnA KVsxfnm flrvw»mrinrin/ri m d mAfA » 
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l^^^^ Bptr0rTrac{ . ft** 1 *** Mrttious Computer Attack** Q' 

tn the computer aocirrtty arena, every now and than, a vulnerability comes along 
CaU3 u!^? slpwlca/rt impact The Impact of a vulnerability fa based on factors such ew 
popularity of the vulnerable platform and the ease of exploitation of the vutoerabilm/ 
^of research gets done on a vulnerable, beginning from lb orfgfn to the variou* 
f!!!^, U combinations of exploit coda that come out subsequent In recent 

S^popu^ 0 Mtf P ro P a 0 iab " ,7 B vxpMt code (In other words, worms) becoming 

Very awe Is known about the events tnWng place In the flme period between the 
" ESSC^J^ ^ ndfah, » t y <»» dfecovefBd by an Indvfdual or a small group of 
mdlvWuaJa, and the moment when uxploft code becomes publicly available on tha 
Internet To zero In on the origins of a parflcular piece of exploit code fa quHe a 
da ™2' ta8ic ' Vary UWo rt^wh ha* bean dona on the subject outsWe 0/ government 

^S^i^^^t?:^" 9 £?S k orifilna * 0 teat.«fip»ctallylfonehas 
taraconetnjct events backwards, tnfs paper addressee this very Issue - trying to it* 
the ram reel backwards from the time the exploit code becomes widespread In public, ■ i 
and «Hnsln the blank frames to the beginning of the movfa. This may not be the 
ultimata "Wg^bang" theory of the exploit universe, but It provides us with new 
viewports on axpldta and their orfgJnotors_- 
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